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FOREWORD 


The  Human  Factors  Technical  Area  of  the  Army  Research  Institute 
(ARI)  is  concerned  with  helping  users  and  operators  cope  with  the  ever 
increasing  complexity  of  the  battlefield  automated  systems  by  which  they 
acquire,  transmit,  process,  disseminate,  and  utilise  information.  In¬ 
creased  system  complexity  increases  demands  imposed  on  the  human  inter¬ 
acting  with  the  machine.  ARI's  efforts  in  this  area  focus  on  human  perfor¬ 
mance  problems  related  to  Interactions  with  command  and  control  centers, 
and  on  issues  of  system  design  and  development.  Research  is  addressed^  to 
such  areas  as  user-oriented  systems,  software  development.  Information 
management,  staff  operations  and  procedures,  decision  support,  and  systems 
integration  and  utilization. 

An  area  of  special  concern  in  user-oriented  systems  is  the  improvement 
of  the  user-machine  interface.  Lacking  consistent  design  principles, 
current  practice  results  in  a  fragmented  and  unsystematic  approach  to 
system  design,  especially  where  the  user/operator-system  Interaction  is 
concerned.  Despite  numerous  design  efforts  and  the  development  of  exten¬ 
sive  system  user  information  over  several  decades,  this  information  remains 
widely  scattered  and  relatively  undocumented  except  as  it  exists  within  and 
reflects  a  particular  system.  The  current  effort  is  dedicated  to  the 
development  of  a  comprehensive  set  of  Human  Factors  guidelines  and  eval¬ 
uation  criteria  for  the  design  of  user/operator  transactions  with  battle¬ 
field  automated  systems.  These  guidelines  and  criteria  are  intended  to 
assist  proponents  and  managers  of  battlefield  automated  systems  at  each 
phase  of  system  development  to  select  the  design  features  and  operating 
procedures  of  the  human -computer  Interface  which  best  match  the  require¬ 
ments  and  capabilities  of  anticipated  users/operators. 

Research  in  the  area  of  user-oriented  systems  is  conducted  as  an 
in-house  effort  augmented  through  contracts  with  uniquely  qualified 
organizations.  The  present  effort  was  conducted  in  collaboration  with 
personnel  from  Synectlcs  Corporation  under  contract  MDA903-80-C-0094. 
The  effort  is  responsive  to  requirements  of  Army  Project  2Q263744A793, 
Human  Performance  Effectiveness  and  Simulation,  and  to  special  requirements 
of  the  U.S.  Army  Combined  Arms  Combat  Developments  Activity  (CACDA),  Fort 
Leavenworth,  Kansas. 

Q  JOSEPH  ZmDVER 

VsJTeahnical  director 
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DESIGN  GUIDELINES  AND  CRITERIA  FOR  USER/ OPERATOR  TRANSACTIONS  WITH  BATTLE¬ 
FIELD  AUTOMATED  SYSTEMS  VOLUME  III-D:  HUMAN  FACTORS  ANALYSIS  OF  USER/ 
OPERATOR  TRANSACTIONS  WITH  THE  INTELLIGENCE  INFORMATION  SUBSYSTEM  FIRST 
MILESTONE  SYSTEM  (IISS-FMS) 


EXECUTIVE  SUMMARY 


Requirement : 

To  develop  a  comprehensive  set  of  human  factorr  guidelines  and  criteria 
for  the  design  of  user/operator  transactions  In  battlefield  automated 
systems  for  use  by  human  factors  specialists  and  system  proponents, 
managers,  and  developers* 


Procedure: 

To  provide  data  for  a  baseline  functional  description  of  user/operator 
transactions  In  battlefield  automated  systems,  user-computer  Interactions 
In  IISS  were  analyzed  using  a  Transaction  Feature  Analysis  technique. 
Data  were  collected  during  interviews  with  system  experts  and  reviews  of 
system  documentation.  The  analysis  focused  on  system  design  features  that 
affect  user/operator  performance  of  transactional  tasks. 


Findings : 

IISS  Is  very  versatile  and  contains  many  design  features  which  should 
make  It  easy  to  use  including  incorporation  of  the  powerful  GIM  language, 
menus  which  require  light  penning  of  desired  options,  and  a  generous  number 
of  both  fixed  and  variable  function  keys.  Advantageous  design  features  are 
not  necessarily  well  designed,  however.  Design  deficiencies  which  are 
especially  Important  include  lack  of  adequate  HELP  information,  cryptic 
error  messages,  absence  of  on-screen  Information  about  legal  command  and 
data  entry  content,  cramped  displays  and  data  entry  formats,  and  poor 
system  response  times.  None  of  the  IISS  human-machine  Interface  problems 
observed  would  cause  the  system  to  fall  catastrophically.  Likewise,  no 
IISS  design  defect  discussed  in  this  report  would  prohibit  IISS  users/ 
operators  from  performing  their  assigned  functions.  Nonetheless,  it  is 
likely  that  many  of  the  problems  would  degrade  system  performance  by 
increasing  user  frustration  and  error  rates,  decreasing  throughput,  and 
compromising  order-of -battle  data  base  quality.  Specific  recommendations 
for  improvements  in  IISS  are  presented  relative  to  each  cited  design 
deficiency. 
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Utilisation  of  Findings: 

Findings  from  the  analysis  of  individual  systems  may  be  useful  to 
proponents  in  specifying  user/operator  requirements  for  future  system 
evolution.  In  this  project,  the  findings  were  incorporated  in  a  data  base 
on  human  factors  requirements  which  provided  the  "real  world"  foundation 
for  development  of  the  provisional  guidelines  and  criteria  presented  In 
volume  IV  of  this  report.  The  provisional  guidelines  and  criteria  will  be 
utilised  as  the  basis  for  development  of  the  prototype  handbook. 


TABLE  OF  CONTENTS 


SUMMARY . .  ,  . .  1 

/ 

PURPOSE  AND  MAJOR  FUNCTIONS  .  5 

RELEVANT  HARDWARE  ELEMENTS . . . .  .  6 

'  \ 

MOBILE  INTELLIGENCE  CENTER . . - .  6 

MOBILE  REMOTE  INTELLIGENCE  TERMINAL .  7 

REMOTE  TERMINALS . 7 

SU  1652  USER  TERMINAL .  7 

OTHER  EQUIPMENT .  14 

RELEVANT  SOFTWARE  ELEMENTS . 14 

GENERAL  STRUCTURE  OF  IISS  SOFTWARE  INTERFACE  .  15  N 

HUMAN-COMPUTER  INTERACTION  MODES  .  17 

Man^Machina  Interface  (MMI)  Mode . 17 

Teletype  Mode . 20 

GIM-II  Language  Mode . 22 

ANALYSIS  OF  TRANSACTION  FEATURES . 23 

SECTION  1.  CONTROL  METHODS . 23 

1.1  Command  Language . 23 

1.1.1  GIM-II  Language . 23 

1.1.2  Man-Machine  Interface  Option  Switches . 26 

1.1.3  Honeywell  TSS  Coiranand/Monitor  Language  .  26 

1.1.4  Honeywell  H-6000  Batch  JCL  .  26 

1.2  Menus . 27 

1.2.1  Light  Pen  Selection  Menus . 27 

1.2.2  Option  Switch  Lists . 27 

1.3  Function  Keys . 28 

1.3.1  Fixed  Function  Keys . 28 

1.3.2  Variable  Function  Keys . 2$ 

1.4  Hybrid  Methods . 31 

1.4.1  Combination  of  Form  Filling,  Menu,  and  Fixed 

Function  Key  Methods  .....  .  31 

1.4.2  Combination  of  Light  Pen  Menu  Selection  and 

Fixed  Function  Key  Methods . 31 

1.4.3  Use  of  Variable  Function  Keys  Throughout  IISS 

Operations . 31 

1.5  Prompts/HELPS . 31 

1.5.1  The  Labels  on  the  Interactive  Forms . 32 

ix 


TABLE  OF  CONTENTS 

(Continued) 


1.5.2  The  "Switch"  Lists .  32 

1.5.3  Menu  Contents . 32 

1.5.4  APP  Option  . .  32 

1.5.5  COPY  Option .  32 

SECTION  2.  DISPLAY  FORMAT .  33 

2.1  Fixed  .Alphanumeric  Displays  .  33 

2.2  Variable-Length  Alphanumeric  Displays  .  ....  35 

2.2.1  User  Messages.  . . 35 

2.2.2  REPORTW  Output .  35 

2.2.3  Output  Using  the  GIM  LIST  Verb .  35 

2.3  Graphic  Displays . 41 

2.4  Highlighting .  41 

SECTION  3.  DATA  ENTRY  ASSISTANCE .  41 

3.1  Information  on  Legal  Entries . 41 

3.1.1  Formatting  Information  . .  42 

3.1.2  Legal  Value  Listing  Where  the  Number  of  Categories 

is  Extremely  Small  .  . . .  .  .  42 

3.2  Unburdening  of  Input . 45 

3.2.1  Encoding  of  Information .  45 

3.2.2  Automatic  Generation  of  UTM  and  GEO  Coordinates.  ...  45 

3.2.3  Automatic  Entry  of  Update  Date  (UDATE) .  45 

3.2.4  Automatic  Update  of  Position  Track  .  45 

3.3  Interrupts  and  Work  Recovery . 46 

3.3.1  Use  of  Defined  Screen  Areas .  46 

3.3.2  Incomplete  JINTACCS  Messages  .  46 

SECTION  4.  MESSAGE  COMPOSITION  AIDS . 

4.1  System  Design  Features .  46 

4.2  Fonnat  for  Alphanumeric  Messages .  47 

4.3  Format  for  Graphic  Messages .  47 

SECTION  5.  DATA  RETRIEVAL  ASSISTANCE  .  47 

5.1  Query  Methods  •  . . 47 

5.1.1  Man-Machine  Interface  (MMI)  Retrievals  .  47 

5.1.2  GIM  Language  Retrievals .  48 

5.2  Query  Structure .  49 


x 


•' ..am  ujii.^«b 


TABLE  OF  CONTENTS 

(Continued) 


SECTION  6.  GLOSSARIES .  49 

6.1  Standard  Terms . 49 

6.1.1  Function  Key  Labels .  49 

6.1.2  Option  Switches . 49 

6.1.3  TACOB  Data  Sets .  50 

6.1.4  IISS  Function  References  in  Menus  and  HELP  Files  ...  50 

6.1.5  command  Language  Terms .  50 

6.2  Character  Sets  and  Labels .  50 

6.3  Glossary  Availability  and  Use . 50 

6.4  Abbreviation  and  Coding . 50 

SECTION  7.  ERROR  HANDLING .  56 

7.1  Error  Prevention  Techniques  .  56 

7.1.1  Field  Size  Indication . 56 

7.1.2  Use  of  Light  Pens . . .  56 

7.1.3  Presentation  of  Data  Element  Labels . .  56 

7.1.4  Indication  of  Active  Screen  Areas .  56 

7.1.5  Automated  Creation  of  Data  Values .  56 

7.1.6  Lighting  of  VFK  Labels .  56 

7.1.7  Presentation  of  "Switch"  Options  .  56 

7.1.8  Availability  of  Various  Data  Formats . .  .  57 

7.2  Error  Detection  Techniques .  57 

7.2.1  String  Length  Evaluation  .  57 

7.2.2  String  Content  Evaluation .  57 

7.2.3  Table  Lookup  Legal  Value  Checks . . .  57 

7.2.4  Conditional  Validity  Checks.  .  . .  57 

7.2.5  Multielement  Data  Sufficiency  Checks  .  57 

7.3  Error  Feedback  Provisions . 58 

7.4  Error  Correction/Recovery  .  58 

SECTION  8.  USER/OPERATOR  CONI' IGURATIONS .  60 

CONCLUSIONS .  62 

RECOMMENDATIONS  .  66 


xi 


LIST  OF  TABLES 


Table  1.  Summary  of  Recommended  Design  Features  and 

Extraction  of  Their  Impact  .  2 

Table  2.  Description  of  the  Transaction  Feature 

Analysis  Technique  .  ,  24 

Table  3.  Categories  of  Design  Features  Affecting  User/ 

Operator  Transactions  with  Battlefield  Automated 

Systems . 25 

Table  4.  IISS  Fixed  Alphanumeric  Displays  . . 34 

Table  5.  Special  Characters  used  as  Delimiters  in  IISS . 51 

Table  6.  IISS  Glossary  Availability,  Use,  and  Memory  Burden . 52 

Table  7.  Examples  of  TACOB  Record  Element  Mnemonic  Encoding  .  55 

Table  8.  Error  Messages  Encountered  During  IISS  Operations  .  59 

LIST  OF  FIGURES 

Figure  1.  The  FMS  Mobile  Intelligence  Center  (MIC)  .  8 

Figure  2.  A  Three-Shelter  Mobile  Remote  Intelligence  Terminal 

(MRIT-L)  .  9 

Figure  3.  FMS  Functional  Interrelationships  .  10 

Figure  4.  SU  1652  Keyboard  and  Controls . 12 

Figure  5.  Screen  Areas  of  the  SU  1652  Display  Implemented  in  IISS  ....  13 

Figure  6.  General  Structure  of  IISS  Functional  Capabilities  .  16 

Figure  7.  Master  Menu  of  the  IISS . . .  17 

Figure  8.  GIM-II  Menu  on  the  IISS . ., . 18 

Figure  9.  Preformatted  Display  for  the  Bulk  Data  Transfer  (BDT) 

in  the  IISS  MMI  Mode . .  18 

Figure  10.  User  Status  Report,  Output  from  Selecting  WHO  Option 

on  the  Master  Menu  . . 19 

Figure  11.  The  List  of  Function  Descriptions  Resulting  from 

Selection  of  the  HELP  Option  from  the  Master  Menu . 20 

xii 


LIST  OF  FIGURES  (Continued) 


Figure  12.  The  Control  Data  Display  of  the  PLOT  Function 

in  the  MMI  Mode . 21 

Figure  13.  Remote  Job  Entry  Form . 28 

Figure  14.  Examples  of  User  Message  Form . 35 

Figure  15.  Time  Sharing  System  (TSS)  Displays  of  the  Host 

H-6000  Operating  System  .  .  36 

Figure  16.  JINTACCS  Format  Example . 37 

Figure  17.  Index  List  for  Air  Units  File . 38 

Figure  18.  Completed  IISS  LOGON  Form . 38 

Figure  19.  Full  Record  Display  .....  .  39 

Figure  20.  End-Input  Analysis  Form  .  42 

Figure  21.  Start  Device  Form . 43 

Figure  22.  IN  ANAL  Dissemination  Header  Form . 44 

Figure  23.  UTM-GEO  Conversion  Form . 44 

Figure  24.  Example  of  a  Select ion/ Retrieval  Screen . 48 


xiii 

»  i 


TABLE  OF  CONTENTS 


APPENDIX  A.  TRANSACTION  FEATURE  ANALYSIS  OF  IISS . A-l 

SECTION  1.  CONTROL  METHODS  .  A-l 

1.1  Command  Languages . A-l 

1.2  Menus . A-2 

1.3  Function  Keys . A-1.1 

1.4  Pronpts/HELPS . A-14 

SECTION  2 .  DISPLAY  FORMAT  .  A-21 

2.1  Fixed  Alphanumeric  Displays . A-21 

2, ,2  Variable-Length  Alphanumeric  Displays . a-2 4 

2.3  Graphic  Displays  .  A-25 

2.4  Highlighting . A-26 

SECTION  3.  DATA  ENTRY  ASSISTANCE . A-2  8 

3.1  Information  on  Legal  Entries . A-28 

3.2  Unburdening  of  Input . . . A- 30 

3.3  Interrupts  and  Work  Recovery . A-34 

SECTION  4.  MESSAGE  COMPOSITION  AIDS . ; . A-37 

4.1  System  Design  Features . A-37 

4.2  Format  for  Alphanumeric  Messages . A-38 

4.3  Graphic  Messages . A-46 

SECTION  5.  DATA  RETRIEVAL  ASSISTANCE . A-47 

V 

5.1  Query  Method . A-47 

5.2  Query  Structure . A-48 

SECTION  6.  GLOSSARIES  .  A-52 

6.1  Standard  Terms . A-52 

6.2  Abbreviations  and  Coding . A-53 

SECTION  7.  ERROR  HANDLING . A-54 

7.1  Error  Prevention  .  ' . A-54 

7.2  Error  Detection,  . . A-55 

7.3  Error  Feedback . " . .  A-56 

7.4  Error  Correction/Recovery . A-56 

APPENDIX  B.  SU  1652  FIXED  FUNCTION  KEYS  USED  IN  IISS . B-l 

APPENDIX  C.  SU  1652  VARIABLE  FUNCTION  KEYS  USED  IN  IISS . C-l 

xlv 


TABLE  OF  CONTENTS  (Continued) 


APPENDIX  D.  DISCUSSION  OF  SOFTWARE  ELEMENTS  IN  IISS 

RELATED  TO  USER/CPERATOR  TRANSACTIONS . D-l 


INTRODUCTION . D-l 

GENERAL  STRUCTURE  OF  IISS  FUNCTIONAL  CAPABILITIES  .  D-l 

MASTER  MENU  OPTIONS . D-6 

Start  a  Hardware  Device  (START  DEVICE  Option)  . • .  D-6 

Logically  Disconnect  a  Device  from  IISS  (STOP 

DEVICE  Option)  . D-8 

Sanitize  File  Contents/Output  (SANITIZER  Option)  .  D-9 

Plotting  Installation  and  Order-of-Battle  Data 

(PLOT  Option) . D-9 

Identify  IISS  Users  (WHO  Option)  . D-9 

Request  a  List  of  User  Options  (HELP  Option) . . . D-9 

Change  in  Security  Header  Line  (MARK  Option)  .  .  D-ll 

Send  Message  to  Other  Users  (USER  MESSAGE  Option)  ,  .  D-12 

Connect  to  GIM  Language  Capabilities  (GIM  Option)  .  D-13 

Connect  to  EUCOM  AIDES  H-S000  (TSS  Option) . D-13 

Transferring  Large  Amounts  of  Data  (BDT  Option) . D-15 

Execute  a  Batch  Job  on  the  EUCOM  AIDES  H-6000 

(RJE  Option) . . D-l 7 

Creation  of  JINTACCS  Messages  (IN  ANAL  Option)  .  D-19 

Bypass  Intelligence  Features  of  SU  1652  (TELETYPE  Option)  .  L-22 

GIM  Menu  and  GIM  Language  Options . D-22 

Enter  Commands  Directly  in  GIM  Language  (GIM  LANGUAGE 

Option) . D-26 

Geographic  Coordinate  Conversion  (UTM-GEO  Option) . D-26 

Report  Format  Specification  (REPORTW  Option)  .  D-27 

Retrieval  of  Order-of-Battle  Data  (ANALYSIS  Option)  .  .  .  ,  .  D-29 

Input  of  Order-ofrBattle  Data  (INPUT  Option) . D-34 

Updating  Order-of-Battle  Data  (ANALYSIS  Option; 

DUPDATE  Option)  .....  .  D-35 

Defining  Geographically  Oriented  Searches  (ANALYSIS  Option)  .  D-35 

APPENDIX  E.  DATA  BASE  ELEMENTS  OF  THE  IISS . E-l 

INTRODUCTION . E-l 

ORDER-OF-BATTLE  DATA  BASE.  STRUCTURES . E-l 

TACOB  DATA  BASE  FUNCTIONAL  STRUCTURE  .  .  • . ’  .  E-4 

STRUCTURE  AND  CONTENT  OF  TACOB  DATA  SETS  AND  FIIES . E-5 

APPENDIX  F.  GENERALIZED  INFORMATION  MANAGEMENT  (GIM) 

LANGUAGE  GRAMMAR  AND  SYNTAX  .  F-l 

APPENDIX  G.  SWITCHES  USED  IN  IISS  MMI  FORMS . G-l 


XV 


1  .'/-‘V* 


^l^SgaijiatlaiWaRgKjih  iLfe&bs  ic5i 


LIST  OF  TABLES 


Table  A-l.  Maximum  and  Average  Positional  Errors  Resulting 

from  Error  in  Latitude  and  Longitude  Specification  .  A-22 

Table  A-2 .  XXSS  Error  Conditions,  Error  Messages,  and 

Recommended  Error  Messages  .  A-57 

Table  D-l.  Teletype  Mode  Command  Options . . . D-2  3 

Table  E-l.  Ground  Order-of-Battle  Support  Files  .  E-8 

Table  E-2 .  Fields  Contained  in  EUNXTS  GOB  File . E-10 

Table  E-3.  Fields  Contained  in  the  XNSTF  GOB  File . E-15 

Table  E-4.  Biographical  Data  Set  Support  Files . E-17 

Table  E-5 .  Fields  Contained  in  the  PERSNF  File  of  the 

BIOGRAPHICAL  Data  Set . E-20 


LIST  OF  FIGURES 


Figure  A-l.  Modified  MASTER  MENU . A-4 

Figure  A-2.  Modified  GIM  Menu . A-4 

Figure  A-3.  Analysis  File  Options . . A-4 

Figure  A-4.  Input  File  Options . '  .  .  .  A-4 

Figure  A-5.  Candidate  Bulk  Data  Transfer  Command  Specification 

Sequence . A-6 

Figure  A-6.  Example  of  Menu-Oriented  BDT  Command  Specification 

Sequence . .  A- 7 

Figure  A-7.  Recommended  Change  in  Option  Selection  for  the  IISS 

MASTER  MENU . A-10 


Figure  A-8.  Recommended  Changes  in  Option  Selection  for  the  IISS 


GIM- 1 1  MENU  %  .  . . A-12 

Figure  A-9.  HELP  References  to  Existing  Documentation . A-16 

Figure  A-lo.  HELP  Display  for  Record  Element  STCAT  .  A-18 

Figure  A-ll.  HELP  Display  for  USER  Message  Form  Switches  .  A-18 

Figure  A-13.  JINTACCS  Message  Dissemination  Header  Menus  .  A-40 


xvii 


Amit-ii 


LIST  OF  FIGURES  (Continued) 


Figure  D-l.  General  structure  of  uss  Functional  Capabilities  .  D-2 

Figure  D-2.  MASTER  MENU  of  the  USS . D-3 

Figure  D-3.  Format  of  the  START  DEVICE  Preformatted  Display  .  D~7 

Figure  D-4.  Format  of  the  STOP  DEVICE  Preformatted  Display  .......  D-8 

Figure  D-5.  Format  of  the  User  Status  Report  (WHO)  Preformatted 

Display . D-10 

Figure  D-6.  Format  of  the  HELP  Preformatted  Display . D-ll 

Figure  D-7.  Format  of  the  Classification  Marking  (MARK) 

Preformatted  Display  ....  .  D-ll 

Figure  D-8.  Format  of  the  USER  MESSAGE  Preformatted  Display  .  D-12 

Figure  D-9.  Format  of  the  DATA  BASE  SIGNON  Preformatted  Display . D-14 

Figure  D-10.  Format  of  page  1  of  the  Honeywell  Signon  Dialogue . D-14 

Figure  D-ll.  Format  of  page  2  of  the  Honeywell  signon  Dialogue . D-15 

Figure  D-12.  Format  of  the  Bulk  Data  Transfer  (BDT)  Preformatted 

Display . D-16 

Figure  D-13.  Format  of  the  Remote  Job  Entry  (RJE)  Preformatted 

Display . D-17 

* 

% 

Figure  D-14.  Format  of  the  Input  Analyst  (IN  ANAL)  File  Selection 

Preformatted  Display  .  D-19 

Figure  D-15.  Format  of  the  Input  Analyst  (IN  ANAL)  Dissemination 

Header  Preformatted  Header  Preformatted  Display  .  D-20 

Figure  D-16.  Format  of  the  input  Analyst  (IN  ANAL)  JINTACCS 

Preformatted  Display  .  D-20 

Figure  D-17.  Format  of  the  input  Analyst  (IN  ANAL)  End- Input 

Analysis  Preformatted  Display . ’ .  . . D-21 

Figure  D-18.  Format  of  the  GIM  Data' Base  Signon  Form . .  D-25 

Figure  D-19.  The  GIM  MENU  . . D-25 

Figure  D-20.  Format  of  the  UTM-GEO  Conversion  Form . D-27 

Figure  D-21.  First  Page  of  the  Report  Writer  (REPORTW)  Preformatted 

Display . D-2  8 


xviii 


LIST  OF  FIGURES  (Continued) 


Figure  D-22 .  Second  Page  of  the  Report  writer  (REPORTW) 

Preformatted  Display  .  D-28 

Figure  D-23.  The  GIM  MENU . D-30 

Figure  D-24.  Format  of  the  SELECTION/RETRIEVAL  SCREEN 

Preformatted  Display  from  the  ANALYSIS  Function  .  D-31 

Figure  D-25.  Example  of  an  INDEX  LIST  from  the  ANALYSIS 

Function . * . D-32 

Figure  D-26.  Page  1  of  a  Full  Record  Display  (FRD)  from  the 

ANALYSIS  Function  .  D-33 

Figure  D-27.  Page  2  of  a  Full  Record  Display  (FRD)  from  the 

ANALYSIS  Function . D-33 

Figure  D-28.  Page  3  of  a  Full  Record  Display  (FRD)  from  the 

ANALYSIS  Function  .  ...  D-34 


Figure  D-29.  Format  of  the  Polygon  Search  Form  is  the  ANALYSIS 

Function . D-36 

Figure  E-l.  Communications  Structure  Supporting  Access  to 

ASGOBS  Data  Base . E-2 

Figure  E-2.  Structure  and  interrelationships  in  TACOB 

Functional  Information  Clusters  .  E-6 

Figure  E-3.  Ground  Order-of -Battle  File  Relationship  for  \ 

Validation,  Update,  Retrieval,  and  Translation  .......  E-9 

Figure  E-4.  Biographical  Relationships  for  Creation,  Index, 

Retrieval,  and  Validation  .....  .  E-18 


xix 


SUMMARY 


This  document  reports  a  human  factors-oriented  'analysis  of  user/operator 
transactions  with  the  Intelligence  Information  Subsystem  (IISS) .  Subject 
matter  experts  were  interviewed  and  system  documents  were  reviewed  to  learn 
about  hardware,  software,  and  procedural  design  features  that  affect  these 
transactions.  Observations  were  recorded  with  a  Transaction  Feature  Analysis 
technique  developed  for  this  purpose.  Transaction  features  analyzed  with  the 
technique  were  arranged  by  categories  to  facilitate  presentation  and  discus¬ 
sion. 

IISS  contains  many  design  features  which  should  make  it  easy  to  use. 

These  features  are  not,  however,  always  well  designed.  Nor  are  they  always 
used  for  processes  in  which  they  would  provide  the  most  benefit  to  IISS  user/ 
operators.  Design  deficiencies  which  are  especially  important  include:  an 
almost  complete  lack  of  HELP  information;  generally  cryptic  error  messages; 
the  absence  of  on-screen  information  about  legal  command  and  data  entry  con¬ 
tent;  cramped  display  and  d$ta  entry  formats;  and  poor  system  response 
times.  None  of  the  IISS  human-machine  interface  problems  observed  would  cause 
the  system  to  fail  catastrophically.  Likewise,  no  IISS  design  defect  dis¬ 
cussed  in  this  report  would  prohibit  IISS  users/operators  from  performing 
their  assigned  functions.  It  is  likely,  however,  that  many  of  the  problems 
would  degrade  system  performance  by:  increasing  error  rate;  decreasing 
throughput;  increasing  user  frustration;  and  compromising  order-of-battle 
data  base  quality. 

Recommendations  for  improvements  in  the  IISS  are  summarized  in  the 
table  below.  The  table  is  organized  by  categories  of  design  features  as 
described  in  the  report.  Each  recommendation  is  evaluated  according  to  the 
best  judgment  of  the  analysts  in  terms  of  hardware  changes,  software  repro¬ 
gramming,  or  changes  in  operating  system  procedures.  Evaluations  cannot  be 
expressed  in  quantitative  terms  because  appropriate  data  could  not  be  col¬ 
lected.  Therefore,  the  evaluation  is  expressed  in  terms  of  low  (L) , 
moderate  (M) ,  or  high  (H)  impact  on  hardware,  software,  and  performance. 

A  minus  sign  indicates  negative  impact  (cost)  and  a  plus  sign  indicates 
positive  impact  (benefit) . 
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Table  i 


Summary  of  Recommended  Design  Features  and  Extraction 

of  Their  Impact  , 


CATEGORY 


IMPACT* 


RECOMMENDATIONS 


user 

Operator/ 

Hardware  Software  Performance 


CONTROL  METHODS 


1 . 1  Command  Language 


1 . 2  Menus 


1.3  Function  Keys 


1.4  Hybrid  Methods 

1.5  Prompts/HELPS 


None 


None 


None 


None 


.  Provide  all  GIM-II  capabili¬ 
ties  in  MMI.  None 

.  Increase  amount  of  information 

in  menu  displays,  None 

.  Break  forms  preparation  into 
logical  steps  (START  DEVICE, 

USER  MESSAGE,  BDT,  RJE) .  None 

.  Provide  "front  end"  for  H6000 

RJE  commands .  None 

.  Provide  for  issuing  SEND  com¬ 
mand  without  using  SEND  key.  None 

.  provide  alternative  to  light 

pen  for  menu  selection.  None 

,  Break  GIM-II  MENU  into 

greater  number  of  less  dense 
menus .  None 

.  Include  HELP  displays  for 

function  key  action.  None 

.  Prompt  user/operator  in  use 
of  function  keys.  None 

,*****N0  RECOMMENDATIONS***’  * 
.  Provide  hierarchical,  inter¬ 
leaved  HELP  capability.  None 

.  Provide  legal  values  infor¬ 
mation  in  HELP  files.  None 

.  Provide  prompts  and  HELPS 

for  FFKs  and  VFKs.  None 

.  Make  HELP  display  in  IISS  con¬ 
sistent  with  current  capabili¬ 
ties  .  None 


None 


None 


None 


None 


None 


DISPLAY 


Fixed  Alphanumeric 
Displays 


Variable-length 

Alphanumeric 

Display 

Graphic  Displays 
Highlighting 


Provide  subfield  delimiters 
in  GEO  coordinate  display. 
Provide  subfield  delimiters 
in  date  display. 

Provide  subfield  delimiters 
in  time  display. 

Provide  subfield  delimiters 
in  DTG  display. 

Provide  for  reorganization 
of  index  list  under  user/ 
operator  control. 

Provide  graphic  display 
capability  on  SU  1652. 

Use  highlighting  capabilities 
of  SU  1652  in  appropriate 
situations. 


None 

L- 

'  H+ 

None 

L- 

M+ 

None 

L- 

I.+ 

None 

L- 

L+ 

None 

L- 

L+ 

None 

L- 

M+ 

None 

L- 

M+ 
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Table  1 .  continued 


IMPACT* 


CATEGORY 


RECOMMENDATIONS 


User 

Operator/ 

Hardware  Software  Performance 


DATA  ENTRY  ASSISTANCE 


3.1  Information  on 
Legal  Entries 


3 . 2  Unburdening  of 
Input 


3 . 3  Interrupts  and 
Work  Recovery 


MESSAGE  COMPOSITION 
AIDS 

4.1  System  Design 
Features 


4.2  Format  for  Alpha¬ 

numeric  Messages 

4.3  Graphic  Messages 


Present  legal  input  values 
stored  in  GIM-II  dictionaries. 
Present  legal  values  or  value 
ranges  for  option  switch  para¬ 
meters. 

Present  /FI  as  valid  option. 
Present  legal  values  for  all 
categorical  order-of -battle 
data  base  fields. 

Present  legal  values  for  all 
categorical  JINTACCS  fields 
in  message  preparation. 

Provide  method  for  storing 
retrieval  specifications  for 
later  use. 

Provide  for  using  place  names 
as  center  point  of  circle 
search. 

Provide  for  using  unit  IDs 
and  alternate  names  as  center 
point  of  circle  search. 

Provide  defaults  and  conven¬ 
tions  for  naming  files 
Provide  indication  of  mes¬ 
sages  waiting  in  queue. 

Provide  for  forms  support  of 
partially  completed  JINTACCS 
messages . 


Provide  interleaved  HELP  for 
legal  values  in  JINTACCS 
message  completion. 

Provide  menu-driven  JINTACCS 
message  completion. 

Constrain  JINTACCS  prompts  to 
information  available  from 
Army. 

Provide  for  preparation,  trans 
mission,  and  receipt  of 
graphics  messages. 


Table  1.  Continued 


CATEGORY 

DATA  RETRIEVAL  ASSIST1 
ANCE 

5 . 1  Query  Method 

5.2  Query  Structure 


GLOSSARIES  • 

6.1  Standard  Terms 

6.2  Abbreviations  and 

Coding 

ERROR  HANDLING 

7 . 1  Prevention 

7.2  Detection 

7 . 3  Feedback 

7 . 4  Correction/Recov¬ 

ery 


■  Low,  M  =  Moderate,  H  ® 
pact  (cost) . 


IMPACT* 


RECOMMENDATIONS 


Hardware 


Software 


User 

Operator/ 

Perfozmance 


None 


.  Provide  for  determination  of 
distance  between  two  points, 

.  Provide  verify  capability  for 
deletion  from  multivalued 
fields . 

.  Include  orientation  informa¬ 
tion  in  data  base. 

.  Implement  route  -search  func¬ 
tion. 


None 


None 

None 

None 


L- 


L- 


L- 


M- 


L+ 


M+ 

L+ 

L+ 


.  Establish  and  enforce  consis¬ 
tency  in  IISS  command  termi¬ 
nology.  None 

.  Establish  and  maintain  con¬ 
sistence  in  IISS  codes  and 
abbreviations.  None 


L- 


M+ 


L+ 


*,****N0  RECOMMENDATIONS *H*** 


.  Evaluate  GIM-II  strings  as 
they  are  entered. 

.  Provide  more  informative  and 
tailored  error  messages. 

.  Eliminate  necessity  for  mean¬ 
ingless  changes  to  multi-line 
commands . 


None 

None 


None 


M- 


L+ 


M- 


M+ 


L- 


L+ 


High  impact;  (+)  -  positive  inpact  (benefit) ,  (-)  *  negative 
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PURPOSE  AND  MAJOR  FUNCTIONS 

"The  IZSS  fms 1  is  an  all-source,  mobile,  tactical  intelligence  data  han¬ 
dling  system  " 2  In  part  derived  from  the  Army  System  for  Standard  Intelligence 
Terminals  (ASSIST),  the  FMS  is  an  independent  subsystem  of  the  U.S.  Army 
Europe  (USAREUR)  Command  and  Control  Information  System  (CCIS) .  It  extends 
the  information  processing  and  intelligence  disseminating  capabilities  cur¬ 
rently  provided  by  the  U.S.  European  Command's  Analyst's  Information  Display 
and  Exploitation  System  (EUCOM  AIDES)  and  by  ASSIST.  Indeed,  TRW  provides  a 
software  package  that  upgrades  ASSIST  to  roughly  the  same  capabilities  as  the 
FMS. 

The  major  purpose  of  the  FMS  is  to  assist  intelligence  analyst  users  to 
provide  accurate  and  timely  tactical  intelligence  to  commanders  in  Army  Corps 
and  subordinate  echelons  pf  USAREUR,  down  to  the  division  or  separate  brigade 
level.  Its  primary  functions3  arej 

1.  On-line  ADP  support  to  intelligence  analysts. 

.  2.  Access  to  multiple  intelligence  data  bases  through  remote 
terminals  and  interconnected  facilities. 

3.  Machine-aided  sanitization  of  intelligence  for  release  to 
collateral  systems. 

4.  Acceptance  of  products  from  tactical  collection  systems. 

5.  Processing  of  ELINT  data. 


VaIso  referred  to  in  some  quarters  as  "IISS",  and  in  the  TRW  documentation 
more  simply  as  "FMS". 

2 /Hardware  Operations  Manual  for  Intelligence  Information  Subsystem  (IISS) 
First  Milestone  System  (FMS) .  TRW  Defense  and  Space  Systems  Group,  Docu¬ 
ment  No.  28503-W104-RU-00,  6  June  1979,  page  1. 

3 /These  functions  are  derived  from  the  FMS  Hardware  Operations  Manual  (see 
Note  2  above)  and  from  IISS  User's  Manual .  TRW  Defense  and  Space  Systems 
Group,  Document  No.  28503-W094-RU-00,  10  May  1979. 
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6.  Processing  of  data  base  files  on  record*  extracted  from  the 
EUCOM  AIDES  Integrated  Data  Base  (IDB)  and  the  USAREUR  Inte¬ 
grated  Ground  Ordar-of-Battie  System  (IGOBS)  data  base. 

7.  Dissemination  of  user-to-user  message  traffic  in  FMS  and 
upgraded  ASSIST. 

8.  Access  to: 

a.  FMS  Tactical  Order-of-Battle  (TACOB)  data  base. 

b.  FMS  Training  data  base. 

c.  ASSIST  Locally  Developed  Files  data  bas. . 

d.  EUCOM  AIDES  IDB  (through  time  sharing  and  remote  job 
entry) . 


RELEVANT  HARDWARE  ELEMENTS 

IISS's  hardware  elements  are  contained  in  three  truck-mounted  complexes: 
a  Mobile  Intelligence  Center  (MIC)  and  two  Mobile  Remote  Intelligence  Ter¬ 
minals  (MRITs) . 

MOBILE  INTELLIGENCE  CENTER 

The  MIC  provides  the  primary  FMS  data  base  and  a  master  control  terminal 
for  the  system.  Through  the  Intelligence  Data  Handling  System  Communications  II 
(IDHSC-II)  network,  AUTODIN,  and  local  facilities,  the  MIC  also  serves  as  the 
primary  communication  center  for  the  FMS,  linking  the  MIC  and  MRITs  tc  each 
other  and  to: 

1.  Tactical  collection  system  inputs. 

2 .  EUCOM  AIDES . 

3.  National  files  and  the  DoD  Intelligence  Information  System 
(DODIIS) . 

Each  MIC  contains,  among  other  equipment,  an  AN/GYQ-21 (V)  computer  (based 
on  the  Digital  Equipment  Corporation's  PDP-11/70)  with  a  1.128-Mbyte  memory, 
five  67-Mbyte  disk  drives,  three  nine-track  tape  drives,  a  high  speed  impact 
line  printer,  one  analyst  terminal,  one  computer  terminal,  an  AUTODIN  inter¬ 
face  terminal,  and  high  security  communications  equipment.  The  MIC,  as  shown 


'Ui.  ■"  'I 
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in  Figure  1,  is  housed  in  three  truck-mounted,  radio  frequency  interference 
(RFX)  shielded  shelters. 

MOBILE  REMOTE  INTELLIGENCE  TERMINAL 

The  MR1T  provides  workstations  for  either  three  or  seven  intelligence 
analyst  users,  depending  on  configuration.  Figure  2  shows  a  seven-position, 
large  MRIT  (MRIT-L) ;  a  three-position,  small  MRIT  (MRIT-S)  consists  of  the 
two  outer  shelters  shown  in  the  figure.  Both  the  large  and  small  MRIT  provide 
a  local  data  base,  and  when  deployed  can  also  contain  the  TACOB  data  base. 

Each  also  serves  as  a  secondary  communications  center  for  tactical  collection 
system  inputs  via  AUTODIN,  and  for  the  MRITs'  communications  with  the  MIC, 
other  MRITs,  and  remote  user  terminals. 

The  MRIT  equipment  includes  an  AN/GYQ-21 (V)  with  a  640-Kbyte  memory, 
three  67-Mbyte  disk  drives,  one  nine-track  tape  drive,  a  high-speed,  elec¬ 
trostatic  line  printer,  three  or  seven  analyst  terminals,  a  CALCOMF  990  high¬ 
speed  plotter,  an  AUTODIN  interface  terminal,  and  high  security  communications 
equipment. 

REMOTE  TERMINALS 

In  addition  to  equipment  housed  in  the  MIC  and  MRIT  shelter  complexes, 
the  FMS  also  provides  support  to  remote  terminals.  Currently,  these  terminals 
are  located  at  V  and  VII  Corps,  and  at  PCAC,  66th  MI,  the  U.S.  Command  in  Berlin, 
and  the  USAREUR  Systems  Division.1*  Other  re-rate  terminals  can  be  added  as 
needed,  because  each  MRIT  is  capable  of  supporting  up  to  ten.  Figure  3  shows 
the  functional  interrelationships  of  the  system  components. 

SU  1652  USER  TERMINAL 

Of  greatest  importance  to  this  contract  is  the  hardware  with  which  users/ 
operators  communicate  with  the  system.  The  bulk  of  that  communication  takes 
place  through  OS-389 (V)/G  intelligent  terminals  in  the  Sperry  Univac  type 
SU  1652  configuration. 


k/IISS  User's  Manual,  Figure  2-1,  page  2-6. 
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ENVIRONMENTAL 

SYSTEM 


ENVIRONMENTAL 

SYSTEM 


ENVIRONMENTAL 

SYSTEM 


Figure  1.  The  FMS  Mobile  Intelligence  Center  (MIC).  Reproduced  from  IISS 
Intelligence  Information  Subsystem  for  USAREUR . t  , TRW  pamphlet,  1978. 


Figure  2.  A  Three-Shelter  Mobile  Remote  Intelligence  Terminal  (MRIT-L) .  (An 
MRIT-S  is  formed  by  using  the  two  outer  shelters  above . )  Reproduced  from 
IISS  Intelligence  Information  Subsystem  for  USAREUR .  TRW  Pamphlet,  1978. 


The  SU  1652  user  terminal  contains  dual  screen  CRT 
displays,  a  light  pen  on  the  right  side,  an  alpha¬ 
numeric  keyboard  and  two  types  of  function  keys: 
Fixed  Function  Keys  (FFKs)  and  Variable  Function 
Keys  (VFKs) .  The  FFKs  are  divided  into  three 
groups,  known  s.s  the  upper,  left  and  right  FFKs, 
all  positioned  around  the  alphanumeric  keyboard. 
The  variable  function  keys  (VFKs)  are  located  on 
pads  on  each  side  of  the  left  and  right  FFKs.  The 
term  variable  in  VFKs  means  the  key  can  be  either 
on  or  off,  indicated  by  a  panel  light  next  to  the 
key.  Note  that  the  left  and  right  FFKs  are  dif- 
v  ferent  from  the  VFKs  in  that  they  have  no  on/off 
indicators  and  are  always  active.5 

The  keyboard  configuration  is  displayed  in  Figure  4. 


The  two  CRT  displays  are  subdivided  into  screen  areas  (SA) ,  as  shown  in 
Figure  5.  These  are: 

SA-1  1  line  on  the  top  of  the  left  screen  for  classification. 

SA-2  19  lines  in  the  middle  of  the  left  screen  used  as  the 

major  user  area. 


SA-3  4  lines  on  the  bottom  of  the  left  screen  used  for  mes¬ 

sages. 

SA-4  1  line  on  the  top  of  the  right  screen  for  classification. 


SA-5  19  lines  in  the  middle  of  the  right  screen  used  as  the 

major  user  area. 

SA-6  4  lines  for  Command  Line  input  and  output,  system  status 

messages  and  error  messages. 


The  FFKs  located  around  the  alphanumeric  keyboard  are  used  to  perform 
editing  and  data  positioning  functions  on  the  displayed  data. 


The  SU  1652  User  terminal  features  contain  editing 
capabilities,  such  as  character  insertion  and  dele¬ 
tion,  line  changes,  character  string  block  manipu¬ 
lation  and  storage  of  limited  data  in  the  terminal. 
There  is  one  left  FFK,  the  "SEND  FFK,  ”  that  is  very 
important  to  the  user.  The  SEND  FFK  signals  the 
external  system  computer  to  read  the  data  in  the  SA 
containing  the  cursor  and  transmit  that  data  to  the 
system  computer;  this  is  how  display  data  is  trans¬ 
mitted  to  the  system  computer.6 


S/Ibid,  page  2-29 
*/Zbid,  page  2-29 
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Figure  4.  SU  1652  Keybaord  and  Controls 


The  location  and  function  of  the  SU  1652  fixed  function  keys  are  presented 
in  Appendix  B. 


The  Variable  Function  Keys  (VFKs)  provide  the  user 
a  means  of  making  entries  controlling  his  inter¬ 
active  terminal  environment  and  responding  to  FMS 
prompts.  A  VFK  is  active  when  the  light  indicator 
is  on.  Typically,  the  pattern  of  active  keys  on  the 
left  and  right  pads  can  change  as  a  user  proceeds 
through  a  menu  option.7 

The  location  and  function  of  assigned  VFKs  are  presented  in  Appendix  C. 

OTHER  EQUIPMENT 

There  are  several  other  pieces  of  hardware  with  which  the  user  may  inter¬ 
act  at  times.  These  include  a  line  printer  and  a  plotter.  Acquisition  of 
terminal  printers  is  currently  being  considered.  The  other  hardware  such  as 
the  disk  and  tape  drive,  the  computer,  the  crypto  units  and  AUTODIN  terminal 
are  not  used  by  the  analyst  user/operator.  Therefore,  only  the  interactions 
with  the  user  terminal  will  be  considered  in  this  report. 


RELEVANT  SOFTWARE  ELEMENTS 

The  AN/GYQ-21 (v)  computers  in  the  MIS  and  MRIT  are,  as  noted  earlier, 
based  on  the  Digital  Equipment  Corporation  (DEC)  PDP  11/70.  The  machines 
operate  under  control  of  DEC'S  RSX-11D  operating  system  (OS).  To  satisfy 
the  particular  requirements  of  the  application,  an  FMS  Executive  System 
specifically  written  for  the  IISS  interfaces  with  the  OS  to  allocate  computer 
resources  such  as  memory  and  buffers  to  various  software  tasks,  to  schedule 
execution  of  these  tasks,  and  to  provide  necessary  security  functions.  In 
practice,  the  OS  and  the  executive  are  invisible  to  the  functional  personnel 
who  are  the  system's  primary  users/operators.  For  this  reason,  these  soft¬ 
ware  elements  are  not  discussed  further  in  this  report. 

IISS  basically  uses  the  command  language  method  to  provide  the  human- 
computer  software  interface.  Though  the  system  includes  a  few  menus  and  some 


7 /Ibid,  page  2-34 
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applications  of  a  "fill-in-the-blanks"  approach,  most  transactions  are  per¬ 
formed  by  constructing  command  language  statements,  either  with  or  without 
computer  assistance.  One  can  think  of  IISS  functions  divided  into  two  groups: 
"utility"  functions,  and  data  base  manipulation  functions.  Utility  functions 
are  performed  with  command  statements  using  essentially  the  DEC  monitor  format, 
if  not  precisely  the  DEC  verbs  and  "switches."  Data  base  manipulations,  on 
the  other  hand,  are  performed  with  command  statements  provided  by  DEC  in  its 
Generalized  information  Management  System  II  (GIM-II).-  These  elements  are 
discussed  in  greater  detail  below. 

GENERAL  STRUCTURE  OF  IISS  SOFTWARE  INTERFACE 

1153  provides  twenty-two  separate  functions  to  support  the  data  processing 
requirements  of  its  intelligence  analyst-users/operators.  The  general  structure 
of  these  functions  is  shown  in  Figure  6.  The  figure  illustrates  three  "modes" 
of  human-computer  interaction:  Man-Machine  Interface  (MMI) ,  TELETYPE,  and  GIM 
Language.  The  reader  should  be  advised  that  a  user/operator  is  not  necessarily 
aware  of  being  in  one  mode  versus  another.  Nor  is  there  evidence  that  system 
developers  deliberately  structured  IISS  in  this  way.  However,  Figure  6  pro- 
vidt  .i  convenient  structure  for  discussing  software  elements  relevant  to  this 
projec 

The  figure  shows  that,  after  the  user/operator  logs  onto  the  system,  the 
computer  automatically  displays  a  MASTER  MENU  (Figure  7) .  All  sessions  with 
the  IISS  b.gin  with  this  menu,  and  many  of  them  will  employ  it  one  or  more  times 
subseque  y.  Notice,  however,  that  four  of  the  options  are  restricted  to  per¬ 
sonnel  with  special  training.  Additionally,  although  human-computer  inter¬ 
action  in  IISS  always  starts  with  a  menu,  later  transactions  employ  a  command 
language  method,  for  the  most  part.  The  means  by  which  the  user/operator  con¬ 
structs  command  statements  depends  on  the  "mode"  depicted  in  Figure  6.  These 
modes  are  discussed  on  page  13  and  following;  the  various  software  functions 
are  described  in  Appendix  D. 
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ar trim  am 


MASTER  MENU 


r  CLASSIFICATION 

♦♦♦CAVEAT*** 

MASTER  MENU 

♦START  DEVICE 

GIM 

♦STOP  DEVICE 

TSS 

WHO 

BDT 

HELP 

RJE 

MARK 

IN  ANAL 

USER  MESSAGE 

♦SANITIZER 

♦PLOT 

TELETYPE 

♦Restricted  options 

Figure  7.  Master  Menu  of  the  IISS.  Redrawn  from  IISS  user's  Manual ,  p.  3-5. 

HUMAN-COMPUTER  INTERACTION  MODES 

Man-Machine  Interface  (MMI)  Mode 

The  computer  enters  the  MMI  mode  automatically  whenever  the  user/operator 
selects  any  MASTER  MENU  option  except  TELETYPE  or  GIM-II.  It  also  enters  this 
mode  automatically  if  the  user/operator  selects  GIM,  signs  onto  a  data  base, 
and  then  selects  UTM/GEO,  REPORTW,  ANALYSIS,  or  INPUT  from  the  GIM-II  MENU 
(Figure  6  illustrates  this  progression;  the  GIM  MENU  is  illustrated  in  Fig¬ 
ure  8) .  However  reached,  the  MMI  mode  provides  preformatted  displays  to  assist 
the  user/operator  in  constructing  command  statements  to  perform  the  functions 
available  in  this  mode. ..  Each  display  consists  of  field  labels  to  identify 
the  input  requirements  of  the  function;  each  field  label  is  followed  by  a 
series  of  underlined  blank  characters  to  indicate  the  maximum  number  of  input 
characters.  At  the  bottom  of  the  screen,  the  computer  displays  a  list  of 
"switches”  that  are  associated  with  the  function.  These  switches  are  optional 
software  parameters;  if  the  field  label  is  taken  as  the  verb  of  a  command  state 
ment,  then  the  switches  are  the  parameters  used  to  complete  that  statement. 


CLASSIFICATION 


***CAVEAT*** 

GIM  MENU 
ANALYSIS 


INPUT 


GIM  LANGUAGE 

EUNITS 

ACTF 

EUNITS 

ACTF 

UTM-GEO 

AUNTF 

PLATF 

AUNTF 

PLATF 

REPURTVI 

EOBF 

ESYSF 

EOBF 

ESYSF 

PERSNF 

MDLF 

PERSNF 

MSLF 

RIIF 

PPTGT 

RIIF 

PPTGT 

INSTF 

RWYF 

INSTF 

RWYF 

ARFLDF' 

ARFLDF 

ACTIVN 

TRANSLATE 

COLUMN  *1  FOR  USE  WITH  ALL  DATA  BASES. 

COLUMNS  #2,  #3,  #4,  and  #5  FOR  USE  WITH  THE  TACOB 

DATA  SASE  ONLY 


Figure  8.  GI.M-II  Menu  on  the  IISS.  Redrawn  from  IISS  User's  Manual,  p.  3-36. 


Figure  9  illustrates  a  completed  MMI  Preformatted  display,  in  this  case  a  Bulk 
Data  Transfer  (BDT) . 


CLASSIFICATION 


***CAVEAT*** 


BULK  DATA  TRANSFER  (FILE-TO-FILE) 

OUTPUT:  (170,201  FILER. OAT/FI/SI  :XY  _  _ 

INPUT:  [170,10]  FILE. OAT/FI  _  “ _ 

USE  THIS  SPACE  FOR  TERMINAL^TIxTINPUY:  _ _ _ 


SITE 

/SI: 

FILE 

/FI 

LABEL 

/LB : XXXXXXXX 

APPEND 

/AP 

UPDATE 

/UP 

SWITCHES 

REOPEN  /RO 
SUPERSEDE  /SU 
USER  INPUT  /US 
BLOCK  SIZE  /BS:XXXX 
TAPE  VOLUME  /VL : XXXXXX 


RECORD  SIZE  /RS:XXXX 

MAG  TAPE  FILE  /TP 

RECORD  FORMAT  /RF:XX 

FOREIGN  TAPE  FILE  /TF 


Figure  9.  Preformatted  Display  for  the  Bulk  Data  Transfer  (BDT)  in  the  IISS 
MMI  Mode,  redrawn  from  IISS  User's  Manual,  p.  3-15. 
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The  required  field#  for  a  BDT  are  OUTPUT  and  INPUT;  the  remaining  field 
provides  space  for  optional  text  entry.  To  complete  the  OUTPUT  field,  the 
user/operator  first  enters  a  code  to  designate  the  source  storage  location 
(this  code  is  (170,20)  in  Figure  9).  Next,  a  file  name  and  catalog  are 
entered  to  designate  the  data  to  be  transferred  (FILER.DAT  in  this  example. 
Note  that  these  two  information  items  are  not  prompted;  the  user/operator 
must  retrieve  them  from  memory  or  from  an  off-line  source.  Then,  the  switches 
list  may  be  consulted  to  find  the  code  for  a  disk  file  (/FI)  or  a  magnetic 
cape  file  (/TP;  other  codes  are  provided  to  assist  with  entry  of  block  size, 
record  size,  record  format  and  other  tape  file  characteristics).  Then,  the 
destination  of  the  data  to  be  transferred  is  indicated  by  emering  /SI 
followed  by  a  site  code  (XY)  in  the  example.  A  similar  procedure  is  followed 
to  complete  the  INPUT  field. 

The  BDT  is  one  of  the  simplest  examples  of  the  MMI  mode  of  interaction 
(WHO  and  HELP— Figures  10  and  11  respectively— are  even  simpler,  consisting 
merely  of  lists  of  information  with  no  further  input  required) .  Other  pre- 
formatted  displays  contain  more  explicit  prompting  information  (e.g. ,  the 
PLOT  control  data  format,  Figure  12.  However,  these  more  detailed  displays 


Figure  10.  User  Status  Report,  Output  from  Selecting  WHO  Option  on  the' 
Master  Menu.  Redrawn  from  IISS  User's  Manual,  p.  3-7. 


either  are  reserved  for  specially  trained  personnel  (e.g.,  restricted  options 
such  as  PLOT),  or  have  not  yet  been  implemented  (e.g.,  the  Full  Record  Dis¬ 
play  for  air  units  task  in  the  ANALYSIS  function) ,  according  to  available 


CLASSIFICATION 

HELP  —  HELP  OPTION  (SHORT/LONG  MISSING  LONG  DEFAULTED} 
OPTION  DESCRIPTION 

BDT  BULK  DATA  TRANSFER  - 

COPY  COPY  INPUT  TO  OUTPUT 

DSPLY  DISPLAY  VERB  ENTRY  POINT  FROM  MENU 

GIM  GENERALIZED  INFORMATION  MANAGEMENT 

SYSTEM  (LOCAL) 

HALT  LOGOFF  AND  HALT  TERMINAL 

HEADER  ALTER  SECURITY  HEADER 

HELP  USER  OPTION  LIST 

LOGOFF  LOG  OFF 

MSG  SEND  MESSAGE  TO  USER  LOCAL  OR  REMOTE 

NOTE  COMMENTS,  NO  OPERATION 

PRINT  PRINT  VERB  ENTRY  POINT  FROM  MENU 

RJE  REMOTE  JOB  ENTRY 

SCRTCH  SCRATCH  VERB  ENTRY  POINT  FROM  MENU 

START  START  DEVICE 

STOP  STOP  DEVICE 

TSS  TIME  SHARING  ON  THE  H-6000 

WHO  USER  STATUS  REPORT 


Figure  11.  The  List  of  Function  Descriptions  Resulting  from  Selection  of  the 
HELP  Option  from  the  Master  Menu.  Redrawn  from  IISS  User's  Manual,  p.  3-8. 


documentation.  Regardless  of  the  detail  in  the  display,  after  the  user/operator 
finishes  entering  data,  pressing  the  SEND  key  transmits  the  completed  display 
to  the  computer  for  processing  (in  the  case  of  WHO  and  HELP,  the  user/operator 
presses  another  key  to  return  to  the  MASTER  MENU) . 

Teletype  Mode 

Selecting  TELETYPE  on  the  MASTER  MENU  causes  the  computer  to  enter  the 
TELETYPE  mode.  Human-computer  interaction  is  carried  out  in  this  mode  in  a 
command  language  much  like  that  employed  with  the  monitor  of  the  PDP  11/70. 
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PLOT  CONTROL  DATA 


* 


NAME  OF  FILE  TO  RECEIVE  THIS  DATA:, 
PLOT  ID! _  SCTY  MARK ; 

LOWER  LEFT  GEO: _ 

PROJECTION: _ SPHEROID: _ 

STANDARD  PARALLELS: _ 

LAT  INC.: _ LONG  INC.: _ 

MARGINS:  TOP: _ BOTTOM: _ 

LETTER  SCALE: _ SYMBOL  SCALE;, 

RESOLUTION: _  OVERWRITE: _ 

MEASUREMENT  OVERRIDE: 

LOWER  LEFT:  X: _ Y: _ 

UPPER  RIGHT:  X:  Y: 

V _  ~~ 


TIME:  _ 

UPPER  RIGHT  GEO: _ 

MAP  SCALE: _ MAP  SHEET: 

REF. LONG: _ GRID  TYPE:, 

UTM  INC.: _ 

LEFT: _  RIGHT  _ 

PLOT  COLOR:  PRIORITY: 


LAT : _ . _  LONG: _  I 

LAT: _  LONG: _  j 


Figure  12.  The  Control  Data  Display  of  the  PLOT  Function  in  the  MMI  Mode. 
Redrawn  from  IISS  User's  Manual,  p.  3-48. 


In  TELETYPE,  the  computer  does  not  provide  preformatted  displays  incorporat¬ 
ing  the  prompts  that  are  available  in  the  MMI  mode.  Instead,  the  user/operator 
keys  in  command  verbs  and  parameters  from  memory  or  off-line  references,  with¬ 
out  benefit  of  field  labels,  underline?  to  indicate  field  lengths,  or  lists 
of  appropriate  switches. 

Figure  6  shows  that  at  least  nine  of  the  sixteen  functions  available  in 
the  MMI  mode  are  also  available  in  TELETYPE,  although  the  interaction  methods 
differ.  Available  documentation  suggests  that  the  MARK  function  in  MMI  and 
the  HEADER  function  TELETYPE  are  highly  similar  functionally,  if  not  identi¬ 
cal.  Whether  PLOT  and  IN  ANAL  are  available  in  TELETYPE  as  well  as  MMI  is 
not  clear.  However,  the  documentation  does  indicate  that  DSPLY,  APP,  COPY, 
UPWIC,  and  SCRATCH  are  available  only  in  TELETYPE  (these  and  other  IISS 
functional  software  capabilities  are  discussed  in  Appendix  D) . 

The  user/operator  at  an  SU  1652  terminal  has  the  option  of  using  either 
MMI  preformatted  displays  or  TELETYPE  command  statements  to  execute  functions 
common  to  both  modes.  Thus  TELETYPE  is  available  as  a  backup  in  the  event  of 
partial  failure  of  the  terminal,  for  example  in  the  light  pen.  Also,  TELETYPE 
must  be  used  by  ASSIST  users/operators  who  wish  to  use  IISS  capabilities  but 
do  not  have  an  SU  1652  terminal.  And,  of  course,  TELETYPE  must  be  used  for 
those  functions  listed  above  that  are  peculiar  to  this  mode. 
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GIM-II  Language  Mode 


As  noted  earlier,  most  of  the  functions  executed  in  the  MM!  and  TELETYPE 
modes  may  be  viewed  as  "utility"  functions.  That  is,  they  relate  to  configur¬ 
ing  the  system,  obtaining  user  lists,  reviewing  available  functions  or  the 
contents  of  output  queues,  transferring  data,  exchanging  information  with 
other  users,  and  the  like.  A  primary  function  of  IISS,  however,  is  to  sup¬ 
port  analyst  interactions  with  intelligence  data  bases.  These  interactions 
are  performed  in  the  GIM-II  mode. 

After  logging  on,  the  user/operator  can  select  GIM-II  from  the  MASTER 
MENU.  The  next  step  is  to  sign  onto  one  of  the  system's  data  bases,  cur¬ 
rently  TACOB  (this  and  other  data  bases  are  discussed  in  Appendix  E) .  After 
completing  the  sign-on  procedure,  the  computer  displays  the  GIM-II  MENU. 

Figure  6  shows  that  selecting  any  of  four  options  on  this  menu  will  lead  to 
the  MM I  mode,  where  the  user/operator  can  fill  out  the  appropriate  prefor¬ 
matted  display.  Selecting  the  fifth  option  will  lead  to  the  GIM-II  Language 
mode.  The  GIM-II  Language  is  essentially  a  data  base  management  system; 
like  the  TELETYPE  mode,  it  uses  command  statements  rather  than  preformatted 
displays.  The  major  differences  between  the  two  modes  are  in  the  functions 
available  in  each,  and  in  GIM-II 's  more  extensive  vocabulary.  Of  course,  the 
user/operator  can  reach  GIM-II  through  the  TELETYPE  mode,  as  shown  in  Figure 
6.  In  fact,  this  appears  to  be  the  only  mode  change  that  cam  be  made  with¬ 
out  first  returning  to  the  MASTER  MENU. 


ANALYSIS  OF  TRANSACTION  FEATURES 


Project  personnel  analyzed  IISS  by  means  of  tv/o  primary  methods:  docu¬ 
ment  reviews  and  interviews  with  subject  matter  experts.  In  both  methods, 
personnel  recorded  their  observations  using  a  Transaction  Feature  Analysis 
technique  developed  by  Synectics  for  this  purpose.  Table  2  describes  the 
elements  cf  this  technique. 

The  Transaction  Feature  Analysis  technique  is  useful  in  guiding  the 
analyst  to  detect  and  describe  desirable,  as  well  as  undesirable,  design 
features  affecting  ueer/operator  transactions .  In  the  case  of  desirable 
features,  the  technique  can  capture  lessons  learned  from  one  system  that  will 
be  relevant  to  other,  perhaps  future,  systems.  In  this  way,  the  technique 
can  help  to  overcome  the  problem  of  information  transfer  among  systems.  Of 
course,  when  describing  a  desirable  feature,  the  analyst  enters  a  uniform 
notation  for  Recommended  Resolution:  "None  required." 

Transaction  features  analyzed  with  the  technique  are  organized  according 
to  the  categories  shown  in  Table  3 .  Results  of  the  analyses  are  discussed  in 
the  same  order;  the  individual  analyses  are  presented  in  Appendix  A. 

1 .  CONTROL  METHODS 

Control  methods  are  the  methods  by  which  the  user/operator  controls  the 
sequence  of  execution  of  system  functions.  Using  control  methods,  the  user/ 
operator  instructs  the  computer  which  functions  to  perform,  and  in  what  order. 


Command  Language 


For  the  purpose  of  this  effort,  project  personnel  define  command  language 
as  the  syntax  and  vocabulary  of  system  control  instructions  that  are  entered 
into  the  computer  as  statements  composed  of  words,  abbreviations,  or  codes 
(commands)  and  appropriate  parameters.  Most  typically,  such  statements  are 
entered  by  typing  at  a  keyboard.  Applying  this  definition,  IISS  users  are 
exposed  to  at  least  four  different  command  languages: 

1.1.1  GIM-II  Language.  This  is  the  most  important  IISS  command 
language,  since  detailed  knowledge  of  this  language  allows  the  user  to  perform 
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Table  2 


Description  of  the  Transaction  Feature  Analysis  Technique 


Transaction  feature.  The  analyst  describes  the  type  of  trans¬ 
action  tetr.g  analysed. 

iescroptoon .  The  analyst  describes  how  the  feature  works  in 
system  operations.  The  description  includes  a  specific  example 
of  the  feature  in  straightforward,  operational  terms. 

3eha'.-iorai  Triplication.  The  analyst  describes  the  feature's 
or.paot  cn  the  user's/operator's  performance.  The  description 
includes  what  the  individual  must  do--and  must  not  do— in  using 
t.-.e  feature.  It  also  includes  requirements  imposed  upon  the 
user/eperator  in  terms  of  memory  burden,  error  likelihood, 
skill  requirements,  and/or  other  performance-related  issues. 
Transactional  Implication.  The  analyst  describes  the  feature's 
effect  on  the  system's  processing  operations.  The  description 
includes  issues  such  as  the  system's  ability  to  detect  errors, 
its  error  handling  procedures,  and/or  the  time  required  to  com¬ 
plete  transactions. 

Consequences.  The  analyse  describes  the  feature's  impact  an 
overall  system  performance.  Here,  the  analyat  predicts  ths 
answers  to  questions  such  as  the  following.  What  effect  does 
the  feature  have  on  the  accuracy  and  timeliness  of  the  data 
base?  What  effect  do«3  the  feature  have  on  the  quantity  and 
and  quality  of  output?  will  the  commander's  picture  of  the 
battlefield  be  enhanced  or  distorted?  Will  targets  be  fired 
more  quickly,  or  lost? 

Recommended  Resolution.  The  analyst  describes  specific,  detailed 
remedial  action.  These  recommendations  includa  changes  to 
hardware,  softwere,  or  procedures  that  will  improve  system 
performance . 


Table  3 


Categories  of  Design  Features  Affecting  User/Operator  Trans' 
actions  with  Battlefield  Automated  Systems 


1.  CC5JTR0L  METHODS 


1.1  Command  Languages 

1 . 2  Menus 

1.2  Function  Keys 

1.4  Hybrid  Methods 

1.5  Prompcs/HELPS 

2.  DISPLAY  FORMAT 

2.1  Fixed  Alphanumeric  Displays 

2.2  Vsr isbls- Length  Alphanumeric  Displays 

2.2  Graphic  Displays 

2.4  Highlighting 


3.  DATA  ENTRY  AMD  HANDLING 


3.1  Information  on  Legal  Entries 

3.2  Unburdening  of  Input 

3.3  Interrupts  and  Work  Recovery 

3.4  Manipulating  Stored  Data 


4.  MESSAGE  COMPOSITION  AIDS 


4.1  System  Design  Features 

4.2  Format  for  Alphanumeric  Messages 

4.3  Graphic  Massages 

5.  DATA  RETRIEVAL  ASSISTANCE 


5.1  Query  Method 

5.2  Query  Structure 

6.  GLOSSARIES 

A.  1  Standard  Terms 

6.2  Character  Sets  and  Labels 

6.3  Glossary  Availability  and  Use 

6.4  Abbreviation  and  Coding 

7.  ERROR  HANDLING 

7.1  Prevention 

7.2  Detection 

7 . 3  Feedback 

7.4  Correction/Recovery 


A 


-  ;•;< 


S.  USER/OPERATOR  CONFIGURATION 


8.1 

JJ.2 

8.3 

8.4 


Operator (e)  Only 
Operator.!*)  and  User!*' 
Coeto  inert  User/Operator 
User  and  Operator  chains 


25 


virtuall-y  all  IISS  functions.  The  GIM  Language  is  quite  powerful,  albeit 
somewhat  complex  for  relatively  naive  users.  GIM-II  verbs,  qualifiers,  system 
literals,  and  connectives  are  listed  in  Appendix  F.  Their  functions  are: 

1.  verbs  indicate  to  the  system  exactly  what  activities  are  to 
be  performed. 

2.  Qualifiers  identify  under  what  conditions  certain  activities 
are  to  be  performed.  Conditional  situations  may  be  defined 
mathematically,  list-positionally ,  logically,  or  in  combina¬ 
tions  . 

2.  System  literals  identify  values  (defined  as  literals)  which 
are  necessary  for  system  operation. 

4.  Connectives  bridge  terms  and  phrases  in  GIM-II  commands, 

defining  how  they  should  be  combined  in  order  to  reach 
the  desired  result. 

1.1.2  Man-Machine  Interface  Option  Switches.  These  switches  form  a  type 
of  "command  language"  in  that  they  define  certain  operations  to  be  performed 
when  used  in  particular  situations.  The  switches  are  a  relatively  "syntax- 
free"  command  language,  since  they  are  used  in  essentially  the  same  way  in 
almost  all  situations.'  Some  of  the  switches  require  that  values  be  associated 
with  the  switch,  requiring  that  the  user  learn  a  rudimentary  syntax.  The 
option  switches  are  not  command- language  like  in  that  the  form  of  the  switches 
(and  terse  indications  of  switch  meaning/function)  appear  in  the  working  dis¬ 
plays  on  which  they  can  be  used.  A  listing  of  the  IISS  option  switches  and 
their  functions  appears  in  Appendix  G. 

1.1.3  Honeywell  TSS  Command/Monitor  Language,  when  employing  the  uss 
TSS  option,  the  user  must  be  familiar  with  the  Honeywell  H-6000  command  syntax 
and  structure.  This  command  language  is  not,  strictly  speaking,  an  IISS  com¬ 
mand  language — it  may  be  used  by  IISS  anlayf  s  only  because  IISS  permits 
connection  to  the  EUCOM  AIDES  H-6000.  The  ARI/Synectics  review  did  not  include 
the  TSS  command  language;  it  will  not  be  discussed  further  here. 

1.1.4  Honeywell  H-6000  Batch, JCL.  When  employing  the  IISS  RJE  option, 
the  analyst  must  have  some  knowledge  of  the  H-6000  batch  JCL,  which  is  a  form 
of  command  language.  As  with  TSS,  this  language  is  not  really  an  IISS  fea¬ 
ture.  Rather,  it  is  a  feature  of  the  H-6000  in  its  EUCOM  AIDES  manifestation. 
Since  the  ARI/Synectics  review  did  not  include  the  Honeywell  batch  JCL,  it 
will  not  be  discussed  further  here. 
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1.2  Menus 


IISS  uses  two  general  types  of  menus: 

1.2.1  Light  Pen  Selection  Menus.  These  are  menus  which  are  presented  to 
the  user  which  require  him/her  to  light  pen  a  desired  option.  There  are  essen¬ 
tially  only  2  such  menus  used  in  IISS — the  MASTER  MENU  (see  Figure  7)  and  the 
GIM  MENU  (see  Figure  8) .  These  are  menus  in  the  classic  sense.  The  user  must 
either  select  an  item  from  the  menu,  or  perform  some  other  function  which 
supersedes  or  overrides  the  menu  selection  process  (e.g.,  press  a  fixed 
function  key;  press  a  variable  function  key) . 

1.2.2  Option  Switch  Lists.  The  presence  of  the  option  switch  lists  are 
oresent  on  a  variety  of  IISS  command  forms  (e.g.,  bulk  data  transfer  (BDT)  form 
(Figure  9) ;  remote  job  entry  (RJE)  form  (Figure  13) .  While  these  forms  repre¬ 
sent  what  is  basically  a  "form  filling"  approach  to  the  control  of  IISS  opera¬ 
tions  and  processing,  the  inclusion  of  the  option  switch  lists  provide  a  form 
of  menu.  The  user  need  merely  survey  the  option  switch  lists  to  identify  the 
switch  form  required  for  the  desired  operation,  and  enter  it  into  the  appro¬ 
priate  place  on  the  form. 

The  appearance  of  menus  in  IISS  bespeaks  am  appropriate  concern  on  the  part 
of  the  system  designers  for  the  memory  burden  being  imposed  on  the  analyst- 
users  of  the  system.  Menus  reduce  the  number  of  command  codes  which  must  be 
committed  to  memory.  They  thus  reduce  the  opportunity  for  users  to  misremember 
and  enter  erroneous  commands  they  also  reduce  the  aunount  of  time  required  for 
users  to  look  up  appropriate  commands  in  reference  documents. 

There  are  some  deficiencies  in  the  way  in  which  menus  are  used  (amd  not 
used)  in  IISS: 

1.  The  light  pen  is  used  in  only  two  of  the  menus  in  IISS.  The 
need  for  users/operators  to  transfer  from  light  pen  inter¬ 
action  to  keyboard  interaction  to  guide  IISS  processing  is 
not  the  most  efficient  form  of  interface  possible.  Either 
the  light  pen  should  not -be  used,  or  some  alternative  to  its 
use  provided. 

2.  There  are  a  number  of  command  functions  in  IISS  where  the  use 
of  menu-driven  interaction  would  be  more  convenient  them  the 
method  currently  used. 

3.  The  information  which  does  appear  on  IISS  menus  is  often  need¬ 
lessly  terse. 

i 

i 
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1.3  Function  Keys 


Both  fixed  and  variable  function  keys  form  important  components  of  the 
overall  IISS  command  mechanism.  The  layout  of  function  keys  on  the  SU  1652 
terminal  keyboard  is  shown  in  Figure  4.  Note  that  the  fixed  function  keys  are 
contained  in  three  groupings,  while  the  variable  function  keys  are  contained 
in  two  separate  groupings.  The  two  separate  types  of  functions  are  distin- 


guished 

not  only  by  position,  but 

also  by  general 

command  function. 

/■ - 

CLASSIFICATION 

♦♦♦CAVEAT*** 

REMOTE  JOB  ENTRY 

A 

OUTPUT: 

INPUT: 

DATA, NET  10: 

:::::: 

SWITCHES 

-FILE 

/FI 

♦8L0CK  SIZE 

/BS: XXXX 

-LABEL 

/LB :XXXXXXXX 

♦TAPE  VOLUME 

/VL :NNNNNN 

-APPEND 

/AP 

♦RECORD  SIZE 

/RS.-XXXX 

-UPDATE 

/UP 

♦RECORD  FORMAT 

/ RF:XX 

-REOPEN 

/RO 

♦MAG  TAPE  FILE 

/TP 

-PRIORITY 

/  PR:A 

-SPOOL  TO  PRINT 

/SP 

-SUPERSEDE 

/SU 

♦FOREIGN  TAPE  FILE 

/TF 

-OUTPUT  ONLY 

-ALLOWABLE  FOR  OUTPUT  AND  INPUT 

Figure  13.  Remote  Job  Entry  Form.  Redrawn  from  IISS  User’s  Manual ,  p.  3-17. 


1.3.1  Fixed  Function  Keys.  These  keys  control  highly  terminal -oriented 
functions,  such  as  those  required  for  text  editing  (on  the  screen  of  the  SU  1652), 
those  indicating  that  the  user  is  ready  to  send  information  from  the  SU  1652  to 
the  main  IISS  processor,  and  those  involved  in  selecting  between  the  SU  1652 
dual  display  screens.  These  functions  depend  heavily  on  the  processing  capa¬ 
bility  of  the  SU  1652.  The  fixed  function  keys  are  always  "active;"  that  is, 
their  associated  functions  will  be  enabled  at  any  that  the  key  is  pressed. 


1.3.2  Variable  Function  Keys.  These  keys  control  liss  activities  which 
have  more  to  do  with  the  processor  (AN/GYQ-21 (V) )  than  the  terminal.  The 
SU  1652  processor  must,  of  course,  evaluate  the  key  pressed  and  generate  the 
correct  series  of  codes  to  be  sent  to  the  processor.  In  general,  however,  its 
role  is  merely  one  of  formatting  and  communication.  The  terminal  itself  takes 
no  action  that  is  immediately  evident  to  the  user. 

In  its  IISS  implementation,  the  variable  function  keys  are  "var¬ 
iable"  only  in  that  they  are  not  always  active.  The  actual  function  of  any 
particular  key  is  constant,  assuming  that  it  is  active.  The  function  of  the 
key  will  not  change  during  IISS  operations.  It  should  be  noted,  however,  that 
unlike  the  situation  with  fixed  function  keys — the  action  of  the  variable  func 
tion  keys  can  be  changed  via  terminal  and  system  reprogramming. 

The  function  of  the  variable  function  keys  is  not  labeled  on  the 
key  itself,  but  rather  on  the  transparent  underlays  placed  beside  each  "strip" 
of  keys.  There  are  lights  under  each  key  label  cell.  When  the  function  is 
active,  the  light  under  the  corresponding  key  label  cell  is  lit. 

A  list  of  fixed  function  key  operations  is  provided  in  Appendix  B;  an 
analagous  list  for  variable  function  keys  appears  in  Appendix  C. 

The  extensive  use  of  function  keys  in  IISS  has  several  benefits: 

1.  It  pc j vide s  a  source  of  constant  "prompts"  for  IISS  users,  since 
the  key  labels  are  imprinted  on  the  keys  or  written  in  the  key 
label  cells.  This  reduces  the  memory  burden  on  the  users. 

2.  It  assures  that  terminology  associated  with  particular  functions 
will  be  consistent.  Since  the  labels  are  consistent,  programmers 
maintaining  or  updating  the  system  cannot  mistakenly  introduce 
terminological  inconsistency. 

3.  The  way  in  •*t  ’’.ch  the  variable  function  keys  are  implemented  in 

s  pa*  ilarly  useful  in  reducing  user  memory  burden. 

Some  implementations  merely  label  VFKs  with  numbers,  requiring 
either  that: 

a.  The  users  remember  what  functions  are  associated  with  a 
specific  -"viable  function  key  number. 

b.  A  menu  be  presented  on  the  screen  indicating  what  VFK  is 
to  be  pressed  to  perform  a  particular  function.  Not  only 
does  this  method  burden  system  main  and  peripheral  memory 
resources,  but  it  also  requires  that  the  user  split  atten¬ 
tion  between  keyboard  and  screen. 

The  IISS  implementation  has  neither  disadvantage. 
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There  are,  however,  ways  in  which  the  employment  of  function  key*  could 
be  made  efficient  in  XXSS,  particularly  for  novice  users/operators: 

t 

a.  XXSS  displays  should  indicate  to  the  user/operitor  what  func¬ 
tion  keys  (fixed  or  variable)  are  typically  used  in  conjunction 
with  .the  operations  to  which  the  displays  refer. 

b.  Where  the  list  of  function  keys  and  the  explanation  of  their 
effects  are  too  lengthy  to  place  on  system  displays,  a  "HELP 
function  KEYS"  VFK  could  present  to  the  user  the  list  of  the 
function  keys  active  at  the  current  point  in  IISS  operations. 

c.  Labels  on  the  VFKs  should  be  more  informative— there  is  cer¬ 
tainly  room  in  the  VFK  labels  areas  for  more  text.  More 
informative  labels  would  not  degrade  the  performance  of 
experienced  users/operators,  but  would  make  the  system 
easier  to  use  by  less  sophisticated  individuals. 
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1 .4  Hybrid  Methods 

The  wide  variety  of  command  methods  available  in  IISS  virtually  assures 
that  some  hybrid  methods  will  be  employed.  The  most  significant  and  pervasive 
combinations  employed  in  IISS  are: 

1.4.1  Combination  of  Form  Filling,  Menu,  and  Fixed  Function  Key  Methods. 

Using  the  MMI  forms  to  control  IISS  operations  requires  that  all  three  of 

* 

these  methods  be  employed: 

1.  Form  filling  is  the  core  command  method,  since  codes  must  be 
entered  into  the  MMI  forms  to  define  subsequent  processing 
operations. 

2.  Menu  selection  is  used  to  provide  the  list  of  "switch"  commands 
which  may  be  used  to  complete  the  forms.  This  aspect  of  the 
command  is  advantageous  since  it  obviates  remembering  the 
"switch"  command  language. 

3.  Fixed  function  keys  are  used  to  position  the  screen  cursor 
in  the  appropriate  field  for  switch  entry. 

1.4.2  Combination  of  Light  Pen  Menu  Selection  and  Fixed  Function  Key 
Methods ♦  When  the  MASTER  MENU  and  the  GIM  MENU  are  used  in  IISS,  the  user 
first  uses  the  SU  1652  light  pen  to  select  the  desired  option.  The  user  must 
then  press  the  SEND  key  to  transmit  the  selection  to  the  main  IISS  processor. 

1.4.3  Use  of  Variable  Function  Keys  Throughout  IISS  Operations.  The 
highly  flexible  variable  function  key  configuration  of  the  SU  1652  allows  it 
to  be  used  in  IISS  when  a  variety  of  other  command  methods  are  being  employed. 
In  many  such  circumstances,  the  variable  function  keys  form  a  constantly 
available  set  of  "global  system  options." 

1.5  Prompts/HELPS 

There  is  only  one  HELP  display  contained  in  IISS  (see  Figure  11) .  This  dis¬ 
play  is  accessed  through  the  IISS  MASTER  MENU,  or  through  the  HELP  command 
when  the  TELETYPE  option  of  IISS  is  employed. 

The  availability  of  prompts  within  IISS  differs  with  the  operating  mode 
being  employed.  Some  "prompt"  information  is  always  presented — the  labels  on 
the  FFKs  and  the  illuminated  labels  associated  with  the  VFKs.  When  the  MMI 
forms  and  menus  are  being  used,  there  are  a  variety  of  types  of  prompts, 
including: 
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1.5.1  The  Labels  on  the  Interactive  Forms,  which  indicate  what  informa¬ 
tion  should  be  entered  into  the  "blanks"  on  the  forms. 

1.5.2  The  "Switch"  Lists,  indicating  what  options  are  legal  for  a  given 

form. 

■1.5.3  Menu  Contents >  which  present  tne  available,  legal  options  for  the 

MASTER  MENU  and  the  GIM  MENU. 

v.’hen  in  the  GIM  LANGUAGE  mode,  IISS  prompts  are  much  less  informative. 

The  available  1133  documentation  alludes  to  an  "input  form"  associated  with 
the  GIM  LANGUAGE  mode.  No  example  of  this  form  appears  in  the  documentation, 
so  no  comment  about  the  value  of  the  form  as  a  prompt  can  be  made. 

When  in  TELETYPE  MODE,  the  usual  prompt  available  is  "MNU>,"  indicating 
that  the  user  is  in  TELETYPE  mode  and  is  waiting  for  a  response.  For  some  of 
the  TELETYPE  options,  some  more  detailed  prompts  are  available: 

1.5.4  APP  Option.  After  the  APP  option  is  selected  in  TELETYPE  mode, 
the  system  responds  with  the  following  prompt: 

WELCOME  TO  THE  APPLICATION  TEST. 

ENTER  A  PASSWORD. 

After  the  password  entry,  more  prompt  information  is  presented: 

YOU  HAVE  PASSED  GO.  COLLECT  $200.  (sic) 

ENTER  A  STRING  AND  IT  WILL  BE  ECHOED. 

ENTER  'BYE*  TO  TERMINATE. 

ENTER  'WAIT'  TO  SUSPEND  FOR  10  SECONDS. 

The  input  prompt  appearing  in  the  APP  option  is: 

APP> 

1.5.5  COPY  Option.  When  the  COPY  option  is  selected  from  TELETYPE  mode, 
the  prompt  associated  with  this  option  is: 

COP> 

There  may  be  prompts  available  from  the  TSS  and  RJE  options  of  IISS,  but 
these  would  be  generated  by  the  EUCOM  AIDES  Honeywell  ti-6000 .  Since  the  pro¬ 
ject  team  did  not  have  an  opportunity  to  review  EUCOM  AIDES  characteristics 
in  detail,  and  since  EUCOM  AIDES  is  not  really  a  "subsystem"  of  IISS,  no 
further  comment  will  be  made  on  TSS  and  RJE  prompts. 
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The  lack  of  detailed  help  information  is  one  of  the  most  glaring  defi¬ 
ciencies  of  the  IISS.  There  is  virtually  no  information  on  legal  entries, 
command  and  data  entry  code  and  abbreviation  glossaries,  command  syntax, 
functions  of  the  IISS,  or  the  meaning  of  terminology  used  in  IISS  displays 
and  prompts.  This  kind  of  information  should  be  available  on-line  to  IISS 
users/operators . 

Prompts  in  IISS  are  plentiful,  although  they  are  not  always  as  informa¬ 
tive  as  they  might  be.  More  detailed  prompts  should  be  provided  for  IISS 
capabilities  which  are  not  likely  to  be  used  often,  such  as  the  JINTACCS  mes¬ 
sage  creation  function  (IN  ANAL) . 

2.  DISPLAY  FORMAT 


The  dual  80  column  by  24  line  screens  of  the  SU  1652  provide  a  great  deal 
of  flexibility  in  creating  alphanumeric  displays.  The  "screen  area"  organiza¬ 
tion  of  the  displays  does,  however,  somewhat  constrain  the  available  display 
space.  The  fixed  alphanumeric  displays  appearing  in  IISS  are  listed  in  Table  4. 

IISS  fixed  format  alphanumeric  displays  are  generally  well  organized  for 
readability.  There  are,  however,  two  exceptions  to  this  general  rule: 

1.  Individual  TACOB  fields  are  often  not  organized  for  maximum 
readability.  In  particular,  geographic  coordinates,  UTM 
coordinates,  dates,  and  times  should  be  broken  into  subfields 
for  display. 

2.  Where  display  space  is  not  at  a  premium,  both  the  labels  of 
TACOB  record  elements  and  the  contents  of  those  elements  should 
be  expanded  to  increase  meaningfulness.  A  field  currently 
labeled  RRDAT,  for  example,  might  be  translated  for  the 
user/operator  to  read  READ.  RATE  DATE  or  READINESS  RATING 
DATE.  This  approach  will  be  particularly  useful  where: 

a.  Users/operators  have  not  had  time  to  gain  significant 
experience  in  the  use  of  IISS. 

b.  Functions  are  used  rarely  (e.g.,  IN  ANAL). 
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Table  4 


IISS  Fixed  Alphanumeric  Displays 


TYPE/NAME  OF  DISPLAY 

EXAMPLES 

COMMENTS 

MASTER  MENU 

Figure  7 

Fixed  display  for  an  individual  type  of 
user.  Where  an  option  is  not  valid  for 
a  particular  type  of  user  the  associated 
menu  term  is  not  displayed.  This  pre¬ 
vents  the  user  from  entering  an  illegal 
command. 

. -  . .  . . . 

QIM  MENU 

1 

Figure  8 

Fixed  display  for  an  individual  type  of 
user.  Where  an  option  for  input  is  not 
valid  for  a  particular  class  of  user, 
this  option  is  not  displayed.  This 
prevents  the  user  from  entering  an 
illegal  command. 

MM I  FORMS 

User  Message 

Form 

(Figure  14) 

TSS  Form 
(Figure  15) 

RJE  Form 
(Figure  13) 

BDT  Form 
(Figure  9) 

This  class  of  forms  is  quite  consistent 
in  format,  containing  labels  for  fields 
into  which  option  switches  or  free  text 
information  should  be  entered.  Most 
forms  request  INPUT  and  OUTPUT  defini¬ 
tion. 

CLASSIFICATION 

HEADER 

Figure  5 

Contains  the  classification  and  caveat 
associated  with  the  terminal  session 

Not  alterable  by  user.  Appears  in 
screen  and  screen  area  4  for  right  screen. 

JINTACCS  FORMATS 

Figure  16 

Input  formats  for  creation  of  JINTACCS 
formats.  Consistent  in  format;  follows 
the  JINTACCS  format  conventions. 

INDEX  LISTS 

Figure  17 

Contains  the  information  on  "hits"  of 

TACOB  retrievals.  Presented  in  fixed 
format  although  length  of  the  index  lists  , 
is  variable  (i.e.,  depends  on  the  number 
of  hits  in  the  retrieval).  Available 
documentation  does  not  indicate  whether 
content  of  index  list  is  variable. 

LOGON  FORM 

Figure  18 

Constant  input-prompt  format. 

SYSTEM  STATUS 

Figure  5 

Appears  in  screen  area  6. 

FULL  RECORD  DIS¬ 
PLAY  (INPUT) 

Figure  19 

Used  to  input  information  into  TACOB  data 
bases.  Where  user  has  no  valid  input, 
user  simply  does  not  enter  information. 
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CLASSIFICATION 
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***CAVEAT*** 
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INPUT  :  7  ft  ?  “  ’  " 

message mu  irTamr"T?r“Tff5E“rJrST"nrryTTiMr 

YES  _  '  ~  ~  ~  ”  Z  Z ' 


SWITCHES 


SITE 

/SI: 

RETAIN 

/RE 

OPERATOR 

/OP 

PRIORITY 

/PR  :A 

ALL  USERS 

7AL 

USER  TERMINAL 

/US 

MASTER  TERMINAL 

,'MT 

SPOOL  TO  PRINT0 

/SP 

Figure  14.  Examples  of  User  Message  Form.  Redrawn  from  IISS  User's  Manual, 
p.  3-10. 


2 . 2  Variable-Length  Alphanumeric  Displays 

There  are  essentially  three  types  of  IISS  displays  which  can  be  thought  of 
as  true  variable- length  alphanumeric  displays. 

2.2.1  User  Messages.  Since  the  main  content  of  user  messages  is  in  free 
text,  they  are  highly  variable  in  length  and  format.  The  user  is  completely- 
free  to  format  information  in  any  way  consistent  with  the  limitations  of  the 
IISS  hardware  and  software.  (See  Figure  14.) 

2.2.2  REPORTW  Output .  If  the  user  wishes  to  generate  a  set  of  informa¬ 
tion  from  a  TACOB  data  set  in  a  format  of  his/her  choosing,  the  reportwriter 
(REPORTW)  option  must  be  employed.  This  option  provides  considerable  flexi¬ 
bility  in  organizing  information  for  display;  it  is  inappropriate,  therefore, 
to  comment  upon  the  (Vganization  or  sensibility  of  the  formats  thus  obtained. 

2.2.3  Output  Using  the  GIM  LIST  Verb.  Using  the  gim  language,  the  uss  , 
user  can  indicate  that  a  specified  .subset  of  the  information  is  contained  in  a 
TAC03  data  base.  Unless  such  output  is  under  the  control  of  a  report  for¬ 
matting  option,  the  format  of  output  is  not  controlled  by  the  user. 


- - 

CLASSIFICATION  ***CAVEAT*** 

TERMINAL  AB 
USERID  $  PASSWORD 
IDENT? 

CLASSIFICATION  OF  YOUR  OUTPUT? 

CLASSIFICATION  OF  FILES  YOU  WILL  CREATE? 

SYSTEM? 


Left  Screen  -  TSS  Prompts 


CLASSIFICATION 

TERMINAL  AB 
(PRINT  INHIBIT) 


***CAVEAT*** 


(USERID  $  PASSWORD) 

(STANDARD  WWMCCS  IDENT  IMAGE) 

(3-CHARACTER  WWMCCS  CLASSIFICATION  CODE) 

(3-CHARACTER  WWMCCS  CLASSIFICATION  CODE) 

(ANY  OF  THE  HIS  SUBSYSTEM,  I.E.,  CARDIN,  EDIT,  JOUT,  ETC.) 


Right  Screen  -  User  Entries 


Figure  15.  Time  Sharing  System  (TSS)  Displays  of  the  Host  H-6000  Operating 
System.  Redrawn  from  IISS  User's  Manual,  pp.  3-12,  3-13. 
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sFgment 7o7hIr~ i RTFllT BeScF  FaCTCrT  ' 

AMPN/ 


ScGMENT/COUNTER  INTFlFI  McF- 1 1  TIJ/OTOfT  ' 
AMPN/ 
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SECURITY  CLASSIFICATION 
RELEASE/ 
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AUTOfW  ii7_ :::_/./ 

EXEP,/_ 

OPER/  ~  _  “ 

MSC,I07_  /  /~_~ ' 

PERIOD/ENDTNG:_IIIIIII 
SEGMENT/GENERAL-ENEMY-SITUATION 
AMPN/ . 


Figure  16.  JINTACCS  Format  Example.  Redrawn  from  IISS  User’s  Menus!,  p.  3-22 
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ACFT 
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0 

IT 

I  AIRUNIT1 7 
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35 

ACFT 
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Figure  17.  Index  List  for  Air  Units  File 


IISS  LOGON 

USER  ORGANIZATION:  JOSAC 
USER  NAME :  TOM 
USER  PASSWORD: 


Figure  18.  completed  IISS  LOGON  Form 


INPUT-OUTPUT  SCREEN  FOR  AIR  UNITS  (AUNTF) 


PAGE  1  OF  3 


IAIP.F  ID  AVMPO0902  EFUNC  (2)  . 

RECLS  (6)  AAAA8Q  AF0ID(16)  50?27*1 234-00024 

OLDAT(II)  77052?  _  PLCTR(13) 

ECHLV  (4) 

IAIRU(IO) 

ORTHM'76)  £lMlT07_ 

PUN H (76)  AIRUNIT83  ~  ~  “  _  I " 

»ALT.‘IM(76) 


*fuNlT{7oT 

AIRUNIT04 


•muFtT-  vAruru~FTero7  TeFa?aTe~WTtIT  FoHWTsT 

AFLDF 
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Figure  19.  Full  Record  Display 


- - - - - - 

AUNTF  (CONT)  PAGE  2  OF  3 
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+ACTID(39) _ _ _______ 

*mk?y-i?)~  ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ 

*RMAffK7l3f)  •“ 

l*AAAAB8*THIS  is  the  first  air  unit  remark 
2*AAAA8B*THIS  IS  THE  SECONO  AIR  UNIT  REMARK 


*MULT!-VALUFD  FIELO,  SEPARATE  WITH  COMMAS.  +CANNGT  BE  DIRECTLY  UPDATED. 


Figure  19.  continued. 


AUNTF  (COKT) 


PAGE  3  OF  3 
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Figure  19.  Continued. 
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Variable- length  alphanumeric  displays  are  generally  well  organized 

and  readable.  Three  improvements  might  be  made:  / 

/ 

1.  Provision  of  a  screen  printer  colocated  with  the  GOB  analysts 
who  will  be  using  the  system.  This  will  facilitate  use  of 
listings  which  do  not  fit  on  a  single  SU  1652  display  screen. 

2.  Provision  for  more 'facile  column  justification  and  positioning 
control  in  report  formats  which  are  defined  by  the  users/opera¬ 
tors  (i.e.,  use  of  the  REPORTW  function). 

3.  Provision  for  user  control  of  the  INDEX  listing  to  accommodate 
co  individual  user/operator  requirements  for  "quick- scan"  item 
review  displays. 

2.3  Graphic  Displays 

Mo  true  graphics  or  pseudographics  (i.e.,  graphics  constructed  from 
characters)  are  available  at  the  SU  1652  terminal.  Geographically-oriented 
plots  are  available  using  the  PLOT  option,  but  this  option  is  not  currently 
implemented  for  IISS  analyst  users.  These  plots  must  be  performed  with  the 
assistance  of  highly  skilled  system  operators.  Plots  are  made  on  a  Calcomp 
flatbed  plotter.  The  ARI/Synectics  review  team  did  not  have  an  opportunity 
to  assess  plotter  formats  or  symbology. 

The  addition  of  a  graphics  display  capability  would  be  a  welcome  addi¬ 
tion  to  IISS,  particularly  in  configurations  where  the  users/operators  are 
physically  removed  from  the  IISS  vans/ shelters.  IISS  work  stations  should  be 
equipped  with  digitizing  tablets  or  pads  to  fulfill  the  potential  of  CRT 
graphics  implementations . 

2.4  Highl ighting 

The  SU  1652  has  a  number  of  features  which  could  be  employed  to  high¬ 
light  important  information,  including  brightness  control,  reverse  display, 
and  blinking.  IISS  does  not,  however,  use  any  of  these  forms  of  highlighting. 

3.  DATA  ENTRY  ASSISTANCE 


3.1  Information  on  Legal  Entries 

IISS  provides  relatively  little 
content  of  legal  entry  information, 
vided  appears  in  the  form  of: 


information  on  the  required  format  or 
Legal  entry  information  which  is  pro- 


. » 
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3.1.1  Formatting  Information,  where  the  user  must  provide  input  of 

a  specific  length,  IISS  input  forms  often  contain  information  on  the  number 
of  characters  which  should  be  entered.  This  indication  is  given  in  the  form 
of  "underlines"  associated  with  a  given  input  field. 

3.1.2  Legal  Value  Listing  Where  the  Number  of  Categories  is  Extremely 
Sma 1 1 .  For  example,  when  the  user  indicates  a  desire  to  terminate  generation 
of  a  JINTACCS  format  while  in  IN  ANAL  mode,  the  END-INPUT  ANALYSIS  form  is 

displayed  (Figure  20)  . 


Figure  20.  End-Input  Analysis  Form.  Redrawn  from  IISS  User's  Manual,  p.  3-21. 
Note  that  the  legal  values  are  provided  for  the  potential  responses  to  the 
DISSEMINATOR  field  (Y  or  N) . 

There  are  several  classes  of  information  in  IISS  for  which  legal  values 

information  is  not  provided.  These  include: 

/ 

1 .  Range  of  values  to  be  associated  with  option  switches.  For 
example,  the  switch  for  line  size  in  the  START  DEVICE  form 
(Figure  21)  is  entered  in  the  format: 

/SZ :  N 

where  N  is  the  override  line  size  for  use  in  input  or  output 
file  specification.  The  display  provides  no  information  on 
the  default  line  size,  nor  on  what  values  would  be  legal  as 
values  for  N. 
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CLASSIFICATION 


***CAVEAT***  J 

START  DEVICE  1 


OUTPUT: 
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NOTE:  IF  INTERACTIVE  DEVICE,  ONLY  SPECIFY  ON  OUTPUT  LINE. 


Vs 


J 


Figure  21.  Start  Device  Form.  Redrawn  from  IISS  User's  Manual,  p.  3-6. 


2.  Honeywell  Signon  Information.  No  information  is  provided  for 
WWMCCS  classification  codes  required  for  signing  on  to  the 
EUCOM  AIDES  N-6000. 

3.  Format  for  file  specification,  required  for  identification  of 
both  input  and  output  files,  is  not  identified  in  IISS  displays. 

4.  Codes  for  JINTACCS  message  dissemination  header,  to  be  entered 
into  the  IN  ANAL  Dissemination  Header  Form  (Figure  22) ,  are  not 
available  to  the  user  from  system  files.  It  should  be  noted 
that  the  maximum  size  (which  may  also  be  the  only  legal  size) 
for  the  codes  is  indicated  by  the  "blanks"  or  "underlines" 
associated  with  the  corresponding  field. 

5.  Codes  for  the  main  body  of  JINTACCS  messages  (see  Figure  16  for 
an  example)  are  not  available  to  the  user  from  system  files. 

Legal  or  maximum  input  string  lengths  are  indicated  by  the 
number  of  "underlines"  in  the  JINTACCS  message  blanks. 

6.  Legal  formats  for  UTM-GEO  conversion  are  not  indicated  (see 
Figure  23),  although  the  maximum  string  length  is  indicated 
by  the  number  of  "underlines"  in  the  form. 

7.  Legal  formats  for  TACOB  data  base  entries  (see  Figure  19)  are 
not  provided  in  system  files  or  in  IISS  displays. 

When  the  user  is  in  GIM  Language  or  TELETYPE  modes,  there  is  essentially  no 
legal  value  or  format  information  available  from  IISS. 
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DISSEMINATION  HEADER 

EXPLICIT  ADDRESSEE ( S ) : 

(SEPARATE  WITH  COMMAS )~ 

ACTIVITY: 


TYPE  : 

MESSAGE  TYPE: 
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OTG  : 

PRIORITY  : 

unit  r  ; : 
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01  SUM 
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JRSRR 
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Figure  22.  IN  ANAL  Dissemination  Header  Form.  Redrawn  from  IISS  User's  Manual 
p.  3-20 


r  CLASSIFICATION 


***CAVEAT***  I 


UTM-GEO  CONVERSION 

SPHEROID: _  UTM: _ 

GEO: 


Figure  23.  UTM-GEO  Conversion  Form.  Redrawn  from  IISS  User's  Manual,  p.  3-37. 


3.2  Unburdening  of  Input 


IISS  contains  several  features  which  reduce  the  number  of  activities 
which  users  must  perform  to  control  system  operation  or  to  enter  information 
into  system  files  or  messagess 

3.2.1  Encoding  of  Information.  Much  of  the  user  input  to  nss  is  entered 
in  the  form  of  codes,  rather  than  full  words  or  phases.  This  reduces  both 

the  time  required  to  enter  information  and  the  probability  of  typographical 
error.  This  encoding  appears  in  many  IISS  operations,  including: 

1.  Specification  of  forms  option  switches. 

2.  Input  of  codes  for  JINTACCS  dissemination  headers  and  message 

bodies. 

3.  Input  to  TACOB  files. 

3.2.2  Automatic  Generation  of  UTM  and  GEO  Coordinates,  tacob  data  files 
hold  georeference  data  in  both  UTM  coordinates  and  GEO  (latitude/longitude) 
form.  The  user  does  not  have  to  enter  both  sets  of  coordinates,  however.  When 
one  is  entered,  the  other  is  automatically  generated. 

3.2.3  Automatic  Entry  of  Update  Date  (UDATE).  when  a  new  record  is 
added  to  a  TACOB  file,  the  structure  of  the  data  base  and  system  requires 
that  an  update  date  be  entered.  Instead  of  requiring  the  user  to  enter  the 
date,  the  IISS  system  automatically  assigns  it. 

3.2.4  Automatic  Update  of  Position  Track,  some  intelligence  operations 
require  knowledge  of  the  position  of  enemy  units  over  time.  Thus,  when  a  new 
position  is  identified,  the  old  position  (and  associated  date)  must  be  saved 
when  the  new  one  is  entered.  The  system  automatically  performs  this  operation 
when  new  positions  are  entered. 

There  are  a  number  of  alterations  to  IISS  which  would  reduce  the  input 
burden  on  analysts  considerably.  These  include: 

1.  Capability  to  store  retrieval  strings  for  subsequent  use. 

2.  Capability  to  store  report  formats  for  subsequent  use. 

3.  Capability  to  enter  units  as  the  center  points  of  circle  searches. 

4.  Use  of  the  system  clock  to  automatically  assign  certain  date 
fields  with  provisions  for  analyst  override. 
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5.  Provisions  for  automatic  assignment  of  file  designations,  as 
opposed  to  the  current  method  of  having  the  ueers/operators 
assign  file  names. 

6.  Acceptance  of  either  UTM  or  GEO  data  as  position  indication, 
with  the  system  ascertaining  which  type  of  coordinate  was 
entered. 

7.  Provision  of  informative  menus  for  switch  specification. 

8.  Menu  selection  of  Classification  and  Caveat  headers. 

j .  Automatic  determination  of  Classification  and  Caveat  headers 

based  on  data  base  or  message  content. 

3.3  Interrupts  and  Work  Recovery 

1135  has  two  provisions  for  limiting  the  impact  of  interrupts  in  work 

flew  processing; 

3.3.1  Use  of  Defined  Screen  Areas,  since  the  su  1652  as  used  in  liss 
has  a  number  of  defined  screen  areas,  high-priority  interrupts  need  not 
necessarily  disrupt  ongoing  work.  Messages  and  instructions  routed  to  user 
terminals  while  the  user  is  working  on  other  activities  can  be  made  to  appear 
in  other  screen  areas. 

3.3.2  Incomplete  JINTACCS  Messages.  When  entering  JINTACCS  messages, 
the  user  may  be  required  to  complete  a  higher-priority  activity.  To  save 
the  partially-completed  message,  the  user  may  hit  the  END  MSG  VFK.  This 
permits  the  analyst  to  either  order  dissemination  of  the  message  or  to  save 
the  partially  completed  message  in  a  file.  Saving  the  message  allows  the 
user  to  complete  it  later.  [NOTE:  completion  of  the  message  is  not  supported 
by  the  JINTACCS  forms  available  from  the  IN  ANAL  option;  the  user  must  enter 
the  information  without  supporting  format  and  content  informacion ] . 

4.  MESSAGE  COMPOSITION  AIDS 

4.1  System  Design  Features 

IISS  supports  generation  of  two  types  of  messages:  free-form  analyst- 
to-analyst  messages  and  JINTACCS  messages. 

Analyst-to-analyst  messages  are  largely  free  format;  most  of  the  work 
in  creating  these  messages  will  involve  typing  in  free  text.  Elements  of 
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the  J I NT ACCS  messages  are  also  free  text,  but  there  is  in  addition  a  signifi¬ 
cant  amount  of  highly  structured  categorical  information  in  the  formats. 
Entering  this  highly  structured  information  would  benefit  from  an  input  menu 
approach  rather  than  the  form  filling  strategy  that  is  currently  used. 

4.2  Format  for  Alphanumeric  Messages 

There  is  no  set  format  for  the  analyst-to^analyst  messages  which  can  be 
generated  by  IISS.  The  content  of  the  messages  is  completely  free-form;  the 
analyse  muse  merely  enter  the  desired  information  into  the  USER  MESSAGE  form 
(Figure  14) .  The  switches  listed  at  the  bottom  of  the  form  determine  the  dis¬ 
semination,  file  residence,  and  media  of  the  user  messages. 

J I NT ACCS  messages  are  constructed  in  the  specified  J1NTACCS  format. 

Using  the  IN  ANAL  option,  the  creation  of  JINTACCS  messages  is  supported  by 
message  composition  forms  (see  Figure  16  for  an  example) .  The  format  for 
these  messages  is  precisely  as  specified  by  JINTACCS  personnel;  no  effort 
appears  to  have  been  made  to  alter  the  format.  Although  the  field  labels  are 
all  provided  in  the  message  formats,  the  user  must  be  familiar  with  the  format 
and  content  of  the  information  entered  into  the  forms. 

4.3  Format  for  Graphic  Messages 

IISS  operation  dees  not  entail  composition  or  receipt  of  any  graphic 
messages. 

5.  DATA  RETRIEVAL  ASSISTANCE 
5.1  Query  Methods 

Query  of  TACOB  data  bases  is  one  of  the  primary  functions  of  IISS. 
Therefore,  it  is  imperative  that  USAREUR  GOB  analysts  be  able  to  perform  data 
base  queries  efficiently  and  effectively.  IISS  accommodates  to  the  varying 
experience  of  its  users  by  providing  two  separate  retrieval/query  methods: 

5.1.1  Man-Machine  Interface  (MMI)  Retrievals,  in  this  method  queries 
are  supported  by  detailed  prompting  forms.  The  user  identifies  the  character¬ 
istics  of  the  desired  order-of-battle  records  by  filling  out  a  Selection/ 
Retrieval  Screen  (Figure  24).  Individual  Selection/Retrieval  screens  are 
available  for  each  TACOB  data  set.  After  having  described  the  desired  record 
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CLASSIFICATION  ***CAVEAT*** 


RETRIEVAL  SCREEN  FOR  AIR  UNITS  FILE  (AUNFF) 

IDENTIFIED  UN!T(ID) 

UNIDENTIFIED  UNIT(  iff)"  “  ~  ~  "  “ 


+FH$TR(6)  . 

. 
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— 

+PRSAT(6) 
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CALEG  (2)““  ~ 
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ACFTFjl9)  ”  ~ 

(76) 

PUN  IT ( 76 ) 

EXECUTE: 

ifrDEX: 

MnFCTqIT: 

— 

+RANGE?  ARE  PERMITTED  (1ST  VALUE  MIN.  2ND  VALUE  MAX) 


Figure  24.  Example  of  a  Selection/'Retreival  Screen.  Redrawn  from  IISS  User's 
Manual,  p.  3-41.  (Note;  not  all  field  labels  are  included  in  this  figure  because 
the  photocopy  of  the  document  used  for  analysis  was  unreadable.) 

characteristics,  the  Index  List  (Figure  17)  appears.  The  user  may  light-pen 
any  of  the  "hits"  to  receive  a  Full  Record  Display  (Figure  19). 

5,1,2  GIM  Language  Retrievals,  in  this  method  the  user  enters  GIM  lan¬ 
guage  commands  to  define  the  characteristics  of  the  records  which  are  to  be 
£Q£^iQved.  Use . of  the  GIM  language  reguires  that  the  user  be  familiar  not 
only  with  the  structure  of  the  GIM  query  language ,  but  also  with  the  structure 
and  content  of  the  TACOB  data  bases  from  which  records  are  to  be  retrieved. 

With  either  of  the  query  methods ,  the  user  may  employ  a  predefined  output 
specification  (see  the  discussion  of  the  REPORTW  option  on  page  31),  or  accept 
a  system  default  format  for  individual  records. 

The  MM I  retrievals  are  not  as  flexible  as  the  GIM  Language  retrievals. 

There  are  some  GIM  Language  capabilities  which  are  not  available  via  MMI, 
and  others  which  seem  to  result  in  more  efficient  processing  than  the  ana- 
lagous  MMI  procedures.  For  maximum  system  utility,  the  MMI  should  provide 
all  of  the  capabilities  currently  provided  by  the  GIM  Language.  The  efficiency 
of  the  process  specified  by  either  method  should  be  comparable. 
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RMiSiLLU  *r: 


I?  RrtagTgPCglgMBSaB 


The  structure  of  MMI  retrievals  is  implicit  in  the  structure  of  the  forms 
to  be  filled  out  to  complete  query  specifications.  The  user  must,  however, 
know  enough  about  the  content  of  TACOB  data  bases  to  be  able  to  specify 
retrieval  parameters  based  on  TACOB  file  record  elements.  As  mentioned  earlier, 
IISS  has  no  provisions  for  displaying  legal  value  or  range  information  to  its 
users . 


The  scruccure  of  the  GIM  language  is  in  two  parts — grammar  and  syntax. 

The  GIM  codes,  grammatical  elements  and  syntactical  elements  are  described  in 
some  detail  in  Appendix  F. 

The  utility  of  query  structure  for  IISS  could  be  enhanced  in  at  least  two 

ways : 

1.  Alteration  of  the  DELETE  capability  of  the  GIM  language  to 
require  user/operator  verification  of  deletions  from  multi¬ 
valued  fields. 


2.  Implementation  of  a  route  search  function  to  supplement  the 
circle  and  polygon  geographic  searches  already  provided. 


6.  GLOSSARIES 


6.1  Standard  Terms 

There  are  several  sets  of  terms  which  are  candidates  for  standardization 
throughout  IISS.  These  include: 

6.1.1  Function  Key  Labels.  Terminology  on  IISS  fixed  and  variable  func¬ 
tion  keys  is  standard  throughout  IISS  operations.  This  is  natural  for  the 
fixed  function  keys,  but  the  IISS  treatment  of  variable  function  keys 
assures  that  their  action  will  be  consistent  in  all  system  activities.  Func¬ 
tions  of  VFKs  are  not  altered  across  system  elements  and  features,  though 
they  may  or  may  not  be  available  at  different  times. 

6.1.2  Option  Switches.  The  MMI  forms  associated  with  various  IISS 
operations  depend  partially  on  the  use  of  option  switches  for  control  speci¬ 
fication.  Option  switch  code  structure  and  function  is  an  obvious  potential 
source  of  inconsistency  within  IISS.  The  implementers  of  the  system,  however, 
appear  to  have  taken  appropriate  precautions  to  ensure  consistency.  There  is 
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no  evidence  of  switches  with  the  same  function  having  different  cone  structure, 
nor  of  switches  with  identical  structure  having  different  functions.  The  switch 
list  appears  in  Appendix  G. 

6.1.3  TACOB  Data  Set?.  The  record  element  labels  of  the  TACOB  data, sets 

are  another  obvious  source  of  potential  inconsistency.  If  sLnilai  information 
is  labeled  differently,  users  will  tei.  1  to  make  errors  when  retrieving  from 
different  data  sets.  These  inconsistencies  are  not  serious  in  TACOB  data  base 
record  element  labels ,  although  some  improvements  could  be  made.  A  listing  of 
che  TACOB  record  elements  used  in  IISS  appears  ir.  Appendix-  S .  ' 

6.1.4  USS  Function  References  in  Menus  and  HELP  Files,  in  general,  the  ■■ 
terminology  in  the  MASTER  MENU  (Figure  7),  the  GIM  MENU  (Figure  ■<),  and  the  IISS 
HELP  listing  (Figure  11)  are  consistent. 

6.1.5  Command  Language  Teniis.  Terms  such  as  those  associated  with  the 
GIM  Language  (Appendix  F)  ard  uhose  associated  with  the  TELETYPE  option  of  the 
MASTER  MENU  (pages  16  through  10),  should  be  consistent.  In  general,  there  is 
admirable  consistency  within  IIS5.  There  are,  however,  some  inconsistencies 
between  menu  terms  and  TELETYPE  MODE  commands  which  should  be  rectified. 

6.2  Character  Sets  and  Labels 

IISS  employs  all  of  the  .standard  typewriter  characters.  The  IISS  func¬ 
tions  which  involve  free  text  entry  demand  considerable  flexibility  in  the 
available  character  sets.  Seme  special  characters  are  used  as  special 
delimiters  in  various  IISS  functions;  these  are  listed  in  Table  5, 

6 . 3  Glossary  Availability  and  Use 

The  IISS  term  and  code  3ets  which  can  be  thought  of  as  "glossaries’* 
are  listed  in  Table  6 ,  along  with  an  indication  of  their  availability  and  use 
in  IISS  operations. 

6 . 4  Abbreviations  and  Coding 

Most  IISS  code  sets  employ  mnemonic  abbreviations.  The  rules  for  form¬ 
ing  these  mnemonic  codes  are  apparently  nut  rigorous,  but  they  are  reasonably 
logical.  Table  7  gives  some  examples  of  the  encoding  rules  employed  for 
TACOB  record  element  labels.  The  complete  set  of  record  element  codes  is 
provided  in  Appendix  H 
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Table  5 

Special  Characters  used  as  Delimiters  in  IISS 


SPECIAS-  CHARACTER 

USE/APPLICATION 

Precedes  switch  specification;  delimits  series 
of  switches. 

: 

Separates  switch  from  switch  parameter. 

[  1 

Encloses  UIC  code  in  file  specification. 

_  (underline) 

Indicates  available  blank  space  in  input  format. 

> 

Terminates  system  prompt  in  TELETYPE  mode. 

& 

Mandatory  termination  of  TELETYPE  commands  when 
terminals  other  than  SU  1652  are  used. 

II  IV 

Indicates  literal  values  in  GIM  command  language. 

Separates  subfields  in  GIM  command  lines. 
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Table  7 


Examples  of  TACOB  Record  Element  Mnemonic  Encoding 


Term  to  be 
Encoded 

Context  (Entire  Phrase 
to  be  Encoded) 

Code  Used 

For  Term 

Complete 

Code 

Comment 

Country 

!_ . 

Country  of  control 

CNTY 

CCNTY 

Mnemonic  is 
apparently  for 
"control  country" 

Country  of  allegiance 

C 

CALEG 

| 

Country  of  world 

CNTRY 

CNTRY 

"World"  apparently 
not  involved  in 
code  construction 

I 

Country  of  location 

CO 

COLOC 

I 

Country  of  nationality 

CNTY 

NCNTY 

Country  of  location 

CNTY 

LCNTY 

Message 

Message  text 

MG 

MGTXT 

Message  identification 

M 

MIDENT 

Message  originator 

M 

MORIG 

Message  line  number 

MSG 

MSGLN 

Narrative  text 

NARTV 

NARTV 

"NAR"  is  abbre¬ 
viation  for 
"narrative " 

Equipment 

Equipment  function 

E 

EFUNC 

Equipment  authorized 

EQ 

EgATH 

1 

Equipment  on  hand 

EQP 

EgPOH 

I 

Equipment  type 

EQ 

EgTYP 

i 

Equipment  user. 

E 

EUSER 
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7.1  Error  Prevention  Techniques 

IISS  contains  a  number  of  techniques  designed  to  prevent  errors  of  com¬ 
mand  and  data  input: 

7.1.1  Field  Size  Indication,  on  both  mmi  (process  control)  and  full 
record  displays  (data  entry)  the  field  size  indication  shows  the  user 
unequivocally  how  many  characters  can  be  entered.  There  is  generally  no 
indication  cf  whether  this  number  of  characters  is  the  maximum  number  allowed 
or  the  only  number  allowed. 

7.1.2  Use  of  Light  Pens.  The  use  of  light  pens  for  command  and  file 
selection  allows  the  user  to  select  from  options  which  he/she  is  actually 
looking  at,  rather  than  reading  or  recalling  commands/data  and  entering  the 
commands  at  the  terminal  keyboard. 

7.1.3  Presentation  of  Data  Element  Labels.  The  presentation  of  data 
element  labels  reduces  the  memory  burdens  on  users  by  eliminating  the  necessity 
for  user  recall  of  record  element  mnemonic  labels. 

7.1.4  Indication  of  Active  Screen  Areas.  IISS  indicates  which  screen 
area  of  the  SU  1652  is  currently  active.  This  reduces  the  probability  that 
the  user  will  enter  the  data  in  an  incorrect  screen  area. 

7.1.5  Automated  Creation  of  Data  Values.  Automatic  creation  of  data 
values  such  as  date  and  geographic  coordinates,  reduces  the  burden  on  the 
operator.  A  concomittant  effect  is  reduction  of  the  number  of  items  which 
the  user  must  enter,  thus  reducing  the  opportunity  for  error. 

7.1.6  Lighting  of  VFK  Labels.  VFK  labels  are  lit  when  they  are  active , 
thus  assuring  that  the  user  will  not  waste  time  or  cause  an  error  by  press¬ 
ing  VFKs  which  are  not  currently  available. 

7.1.7  Presentation  of  “Switch"  Options.  The  presentation  of  "switch" 
options  on  MMI  forms  assures  that  the  user  is  constantly  presented  with  all 
legal  values  where  switch  options  are  available. 
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7.1,8  Availability  of  Various  Date  Formats.  For  most  tacob  "date"  record 


elements,  the  user  can  enter  dates  in  any  of  the  following  formats: 

1.  January  15,  1974 

2.  15  Jan  1974 

3.  15  Jan  74 

4.  1-15-74 

5.  1/15/74 

6.  14  January  1974 

7.  15-Jan-74 


Even  if  the  user  foraets  one  of  the  date  formats,  it  is  likely  that  any  rational 
date  entry  rorrcat  will  be  accepted  by  IISS. 


7.2  Error  Detection  Techniques 


The  GIM  DBMS  employed  in  IISS  has  a  number  of  capabilities  for  error 
detection.  These  capabilities  are  employed  to  maintain  data  base  integrity, 
and  include: 


7.2.1  String  Length  Evaluation.  The  system  checks  the  input  to  deter¬ 
mine  v/hether  the  character  string  entered  is  of  appropriate  length.  GIM  can 
check  for  both  maximum  and  minimum  string  length  limitations. 


7.2.2  String  Content  Evaluation,  if  input  values  are  to  be  limited  to 
a  small  number  of  predetermined  values  (e.g.,  "H"  for  high,  "M"  for  medium, 

"L"  for  low) ,  GIM  can  test  to  determine  whether  the  input  contains  one  of  these 
legal  values.  This  techniques  is  used  to  check  for  legal  input  values  for  the 
STCAT  (strength  category)  record  element  of  the  EUNITS  File,  for  example. 

Here  the  legal  values  are  "0,"  "N,"  "E,"  and  "C." 


7.2.3  Table  Lookup  Legal  Value  Checks,  where  the  number  of  legal  values 
for  a  record  element  is  large,  the  GIM  software  can  check  the  input  string 
against  a  table  of  legal  values.  This  techniques  is  used  to  evaluate  country 
code  inputs  in  IISS. 

7.2.4  Conditional  Validity  Checks.  The  input  is  evaluated  against 
other  data  already  contained  in  the  TACOB  data  set.  Relational  and  arithmetic 
rules  determine  whether  the  input  is  valid. 
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7.2.5  Multielement  Data  Sufficiency  Checks.  Some  data  elements  in  TACOB 
files  can  only  be  entered  if  a  corresponding  data  element  is  also  entered. 

For  example,  when  a  new  location  (GEOLO  or  UTMLO)  is  entered  to  an  EUNITS 
record,  the  corresponding  "change  location  date"  (CLDAT)  must  also  be  entered. 
This  assures  that  the  USAREUR  analysts  will  know  how  current  position  reports 
are.  The  GIM  software  of  IISS  performs  these  checks. 

Error  detection  would  be  improved  if  errors  in  GIM  Language  command 
elements  were  detected  as  the  user  types  them  into  the  terminal.  This  approach 
would,  of  course,  require  the  use  of  the  local  processing  capabilities  of  the 
SU  1652.  For  a  completely  satisfactory  implementation  it  might  require  pro¬ 
vision  of  local  (i.e.,  SU  1652-controlled)  peripheral  memory  (such  as  floppy 
disks)  . 


7.3  Error  Feedback  Provisions 

IISS  provides  a  number  of  error  messages  in  screen  area  6  (bottom  of  the 
right  screen  on  the  SU  1652).  A  complete  list  of  error  messages  is  included 
in  Appendix  I .  This  list  includes  a  number  of  error  and  systems  messages 
which  are  not  tied  to  user  errors  per  se,  but  which  may  result  from  system 
errors  or  programming  errors  (e.g.,  INVALID  EXTENDED  STORAGE  SUBPOOL?  SUPERVISOR 
DIRECTIVE  FAILURE;  WRITE  ERROR  ON  MSNTOS  FILE).  The  available  documentation 
is  unclear  about  whether  such  messages  are  ever  presented  to  the  USAREUR 
analysts  who  use  IISS.  If  they  are,  it  is  likely  that  they  would  not  be 
particularly  meaningful.  The  error  messages  in  Appendix  I  appear  in  Appendix 
B  of  the  IISS  USER'S  MANUAL.  The  list  is  apparently  not  comprehensive,  however, 
since  examples  of  processing  contained  in  the  IISS  TACOB  DATA  BASE  USERS  GUIDE 
list  error  messages  which  are  not  contained  in  Appendix  B .  Some  examples  of 
these  error  messages  are  contained  in  Table  8 .  These  examples  are  derived 
from  IISS  interaction  in  the  GIM  LANGUAGE  mode,  but  it  is  presumed  that  the 
same  sorts  of  error  feedback  occur  during  MMI  interaction.  Note  that  this  is 
far  from  an  exhaustive  list?  the  available  documentation  and  extent  of  on-site 
data  collection  did  not  permit  a  comprehensive  listing  of  error  code  types  and 
associated  error  messages. 


7 . 4  Error  Correction/Recovery 

Once  errors  have  been  detected,  they  can  be  corrected  in  one  of  two  ways: 
The  screen  area  may  be  cleared,  and  the  entire  statement  re-entered.  Or,  the 

58 


'I.  -i* K 1 S V-J 1  SdSEEtSSH 


Error  Messages  Encountered  During  IISS  Operations 


*> 


screen  editor  and  cursor  FFKs  of  the  SU  1652  may  be  used  to  correct  the  error 
in  the  command  or  data  entry  input. 

The  IXSS  system  does  not  evaluate  command  lines  or  data  entry  codes  as 
they  are  typed  onto  the  terminal  screen.  Rather,  the  information  is  evaluated 
after  the  information  is  transmitted  to  the  IISS  processor  (i.e.,  after  the 
SEND  FFK  is  pressed) .  The  available  documentation  did  not  indicate  how  legal, 
but  erroneous,  process  control  specifications  may  be  terminated  (e.g.,  how  to 
interrupt  a  geographic  search  where  geographic  parameters  are  incorrect) . 

3.  USER/OPERATOR  CONFIGURATIONS 

There  are  essentially  five  types  of  user/operators  in  the  IISS  system: 

1.  USAREUR  HQ  GOB  analysts. 

2.  CORPS- level  GOB  analysts. 

3.  Intelligence  Support  Element  (ISE)  personnel. 

4.  IISS  system  operator  personnel. 

5.  G2  command  personnel. 

The  first  three  types  are  essentially  similar.  The  USAREUR  HQ  GOB  analysts 
perform  ail  of  the  TACOB  (or  other  GOB  file  updates) ,  while  the  Corps-level 
and  ISE  users  typically  perform  only  retrievals.  Restrictions  on  user 
activity  are  easily  controlled  by  system  personnel,  so  it  is  not  inaccurate 
to  consider  the  first  three  types  as  essentially  identical. 

The  ARI/Synectics  review  did  not  evaluate  the  role  of  the  IISS  system 
operator  personnel.  During  on-site  observations,  these  personnel  were  pri¬ 
marily  supporting  the  operations  of  the  analyst-users.  There  was  insuffi¬ 
cient  time  to  perform  adequate  analyses  of  both  classes  of  "hands-on"  users/ 
operators;  reviewing  analyst/system  interface  was  selected  as  being  of  higher 
priority. 

The  role  of  the  G2  command  personnel  was  evaluated  only  tangentially. 
These  personnel  have  an  extremely  significant  role,  since  they  often  develop 
the  intelligence  problem  sets  which  define  the  system  interaction  requirements 
for  the  GOB  analysts. 
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Ignoring  the  role  of  the  IISS  system  personnel,  there  are  essentially 
Two  user/operator  configurations  which  are  important  in  IISS  operations: 

1.  GOB  analysts  operating  autonomously.  There  are  many  tasks 

which  the  GOB  analysts  will  perform  with  little  or  no  supervi¬ 
sion  from  or  coordination  with  G2  command  personnel.  Most  of 
the  data  base  updates,  for  instance,  can  only  be  performed  by 
the  GOB  analysts  themselves.  A  complete  and  up-to-date  data 
base  is  critical  to  the  overall  utility  of  IISS.  Updating  it 
is  in  essence  a  "background-mode"  operation:  updates  must  be 
performed  when  time  is  available  and  when  critical  retrievals 
are  not  required  by  command  personnel. 


GOB  analysts  operating  under  direct  supervision  of  G2  personnel. 
Particularly  during  crisis  periods  battlefield-echelon  intelli¬ 
gence  officers  will  be  attempting  to  collect,  coordinate,  and 
analyze  intelligence  of  direct  relevance  to  combat  commanders. 
Since  IISS  will  be  a  significant  resource  for  order-of-battle 
information,  it  is  likely  that  intelligence  officers  will  be 
interacting  directly  and  frequently  with  IISS  GOB  operator/ 
analysts. 


CONCLUSIONS 


The  Intelligence  Information  Subsystem  (XISS)  First  Milestone  System 
(FMS)  appears  to  incorporate  all  important  functions  required  to  support 
U.S.  Army  Ground  Order-of-Battle  (GOB)  analysts  in  establishing,  maintaining, 
and  exploiting  order-of-battle  files.  There  is  no  technical  reason  why  it 
should  not  prove  to  be  a  significant  asset  to  Army  intelligence  and  command 
missions.  The  designers  of  the  system  made  serious  attempts  to  make  IISS 
simple  tor  its  users/operators  to  use,  providing  such  features  as: 

1.  Menu  selection  of  major  system  functions, 

2.  Use  of  light  pens  for  menu  selection. 

3.  A  potentially  powerful  and  informative  error  detection  and 
feedback  system. 

4.  A  dual-screen  CRT  with  powerful  local  processing  capabilities, 
which  expands  opportunities  for  providing  system  users  with 
convenient,  informative  interfaces  with  IISS  hardware  and 
software. 

5.  Extensive  use  of  fixed  and  variable  function  keys  for  text¬ 
editing  and  process  control. 

With  capabilities  and  characteristics  like  these,  IISS  should  be  one  of  the 
most  user-oriented  systems  extant.  Unfortunately,  it  falls  short  of  its 
potential  in  most  areas  of  human  factors  design. 

IISS  does  indeed  incorporate  many,  if  not  most,  of  the  design  features 
which  could  be  recommended  for  a  system  like  it.  But  the  potential  of  these 
design  characteristics  is  typically  not  realized  throughout  the  system. 
Examples  of  outstanding  design  appear  at  various  points,  but  are  replaced  by 
inferior  methods  in  situations  where  they  might  be  even  more  profitably 
employed.  Areas  in  which  desirable  IISS  design  features  are  not  used  through¬ 
out  the  system  include: 

1.  Access  to  HELP  information.  IISS  contains  a  single  HELP  display 
which  provides  brief  descriptions  of  the  major  functions  of  IISS. 

No  other  HELP  displays  are  provided. 

2.  Use  of  informative  menus.  IISS  uses  menu  selection  for  commands 
in  its  MASTER  MENU  and  GIM  MENU.  Yet  other  functions  employ 
inferior  methods,  even  though  there  is  even  more  need  for  con¬ 
veying  detailed  information  to  the  user/operator  to  support 
complex  command  and  data  entry  decisions. 
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3.  Error  message.  The  Generalized  Information  Management  System 
used  in  IISS  contains  powerful  error  detection  and  feedback 
capabilities.  The  language  contained  in  error  messages  is, 
however,  often  too  formal  and  stilted.  Error  messages  appear 
to  presume  that  users/operators  will  be  relatively  familiar 
with  ADP  and  data  base  structure  terminology.  And  some  mes¬ 
sages  simply  do  not  contain  enough  information  about  the  error 
to  guide  users/operators  to  the  appropriate  remediation  mea¬ 
sures  . 

4.  Information  on  legal  entries.  Certain  IISS  command  forms  use 
"switches"  to  define  user/operator  command  intentions.  These 
switch  options  are  displayed  on  the  command  forms,  providing 
information  on  legal  form  entries.  But  information  on  para¬ 
meters  associated  with  the  switches  is  not  provided.  Worse 
yet,  information  on  legal  entries  is  notably  lacking  in  data 
input  situations;  it  is  provided  only  in  inconvenient  and 
easily  mislaid  system  documentation. 

5.  Consistency  in  command  and  data  entry  terminology.  In  general, 
terminology  in  IISS  is  admirably  consistent.  There  are,  however, 
some  gratuitous  and  aggravating  deviations  from  consistency 
which  unnecessarily  reduce  the  system's  ease  of  use. 

C 

Proliferation  of  these  features  throughout  IISS  would  tremendously  increase 
the  capability  of  users/operators  to  profitably  employ  its  capabilities. 

In  addition  to  design  features  which  already  exist  in  some  form  within 
IISS,  there  are  others  which  might  be  used  to  enhance  the  system's  user  inter¬ 
face.  These  features  are  discussed  in  detail  in  other  sections  of  this  report, 
and  will  not  be  discussed  in  detail  here.  It  must  be  noted,  however,  that 
IISS  is  far  from  the  worst  interactive  system  which  has  been  created  in  recent 
years.  There  are,  in  fact,  significantly  i,»i“rior  examples  within  the  cur¬ 
rent  Army  retinue  of  battlefield  automated  systems.  It  is  also  important  to 
realize  that  IISS  is  not  in  any  way  an  "unusable"  system.  Given  sufficient 
training  and  experience,  many  Amy  intelligence  analysts  should  be  able  to 
master  the  intricacies  of  the  system.  In  peacetime  situations  the  design 
deficiencies  may  not  even  impact  severely  on  IISS  operational  throughout  and 
data  base  integrity.  But  IISS  is  a  tactical  system.  In  battle,  or  even  in 
periods  of  crisis,  deficiencies  which  ordinarily  seem  trivial  may  be  vastly 
magnified.  Where  an  error  in  the  position  of  an  enemy  unit  would  be  detected 
and  eventually  rectified  without  consequence  in  peacetime,  it  may  result  in 
the  unanticipated  appearance  of  enemy  forces  on  an  exposed  flank  in  time  of 


war.  Intelligence  analysts  exposed  to  the  stresses  and  rigors  of  combat 
deset  re  the  most  capable,  easiest  to  use  ADP  systems  which,  modem  technology 
can  provide.,  Potentially  modest  enhancements  to  IISS  should  yield  significant 
benefits  in  this  regard. 

It  would  be  inappropriate  to  end  this  discussion  of  conclusions  about 
IISS  without  considering  factors  which  mitigate  the  strength  and  conviction 
with  which  they  can  be  made.  There  are  at  least  four  situations  which  affect 
any  conclusions  which-  might  be  drawn: 

i.  The  developmental  status  of  IISS.  IISS  is  in  its  initial 
fielded  configuration;  it  is  apparent  that  many  aspects  of 
its  design  are  not  yet  optimized.  It  tnay  be  that  many  of  the 
suggestions  contained  in  this  document  are  already  planned  and 
are  awaiting  initial  user  feedback  for  detailed  design  direc¬ 
tion.  It  is  also  possible  that  some  of  the  observed  "design 
defects"  are  not  design  defects  at  all,  but  are  rather  results 
of  previously  undetected  bugs  in  system  or  applications  soft¬ 
ware. 

Lack  of  operational  exercise  experience.  IISS  was  observed 
during  the  course  of  a  military  exercise,  but  it  was  not 
specifically  an  intelligence  exercise.  The  conditions  of  the 
exercise  probably  did  not  realistically  duplicate  those  which 
would  exist  in  wartime  intelligence  analysis.  Design  features 
which  currently  seem  acceptable  may  turn  out  to  be  intolerable 
in  more  rigorous  operational  contexts;  those  which  currently 
'ear  as  glaring  deficiencies  may  cause  little  or  no  problems 
r.*  actual  system  operation.  One  of  the  primary  purposes  of 
this  document  is  to  provide  IISS  developers  and  proponents 
with  a  body  of  opinion  about  the  human-machine  interface.  The 
kind  of  human  factors  analysis  which  was  performed  attempts  to 
encapsulate  and  distill  the  results  of  previous  experience  and 
research  results.  It  is  recognized,  however,  tnat  every  system 
implementation  is  unique,  and  must  operate  in  a  unique  environ¬ 
ment.  The  results  of  more  operationally  realistic  exercises 
must  be  used  to  temper  and  evaluate  the  conclusions  and  recom¬ 
mendations  presented  here. 

Unintended  employment  of  system  capabilities.  During  the  ARI/ 
Synectics  observation  of  IISS  operation,  it  became  apparent  that 
the  GOB  analysts  using  the  system  were  not  using  it  as  its 
designers  intended.  IISS  was  designed  primarily  as  an  order- 
of-battle  data  storage,  maintenance,  and  exploitation  system. 

The  systems  analysts,  programmers,  operators,  and  training 
personnel  associated  with  IISS  estimated  that  80  to  S0  percent 
of  interactions  with  the  system  were  to  send  or  receive  user 
messages.  The  relative  paucity  of  analyst  employment  of  core 
IISS  capabilities  may  have  colored  perceptions  of  system  char¬ 
acteristics  to  the  detriment  of  this  analysis. 
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Lack  of  an  appropriate  data  base.  One  of  the  most  consistent 
criticisms  of  IISS  concerned  the  structure  and  content  of  the 
TACOB  data  base.  It  does  not  seem  to  have  been  designed  with 
the  needs  of  its  principal  users  (Army  GOB  analysts)  in  mind. 

Many  TACOB  files  are  not  used  by  the  analysts;  some  of  the 
most  vital  data  elements  are  missing  from  the  files  which  are 
used.  It  is  difficult  to  determine  exactly  what  effect  this 
has  had  on  the  analysis,  but  it  is  likely  that  the  scope  and 
emphasis  of  the  investigation  would  have  been  different  had 
a  finalized  data  base  structure  existed.  Some  of  the  criti¬ 
cisms  included  in  this  document  are  direct  results  of  the  way 
in  which  TACOB  is  structured.  It  is  hoped  that  the  deficien¬ 
cies  which  led  to  these  criticisms  will  be  corrected  in  the 
improved  data  base  structure  currently  being  developed. 

One  observation  which  can  be  made  about  IISS  is  not  strictly  speaking  of 
human  factors  concern.  The  observation  is  this;  system  retrievals  are  simply 
too  slow.  A  complex  retrieval  from  a  2000  record  data  base  can  require  more 
than  30  minutes.  This  seems  highly  inappropriate  for  a  tactical  data  system, 
and  must  be  extremely  frustrating  to  system  users.  It  is  conceivable  that  the 
slowness  of  the  system  may  be  one  reason  why  the  order-of-battle-related 
capabilities  are  not  often  employed  by  IISS  users/operators.  While  there  are 
some  methods  for  overcoming  the  system's  speed  deficiencies,  they  are  appar¬ 
ently  not  easy  for  the  analysts  to  use. 


RECOMMENDATIONS 


Specific  recommendations  for  altering  the  IISS  human  system  interface  are 
discussed  briefly  in  the  "Analysis"  section  of  this  report.  These  recommenda¬ 
tions  are  further  detailed  in  the  Transaction  Feature  Analyses  contained  in 
Appendix  A.  The  detailed  suggestions  will  not  be  repeated  here,  but  a  summary 
of  their  primary  intent  is  appropriate.  IISS  human-machine  interface  could 
profit  from  application  of  the  following  general  principles: 

1.  Provide  more  information  on  command  structure  and  effects.  This 
sort  of  information  is  currently  available  only  in  system  docu¬ 
mentation.  Summarized  versions  of  this  information  in  IISS  HELP 

-  files  would  substantially  enhance  system  utility. 

2 .  Provide  much  more  detailed  information  on  legal  entries.  Except 
for  indications  of  the  maximum  length  of  input  strings,  IISS 
contains  virtually  no  information  on  legal  value  content  and 
format.  Provision  of  legal  value  information  would  simplify 
entry  of  both  order-of -battle  data  and  message  content.  If 
possible,  legal  entries  information  should  be  contained  in 
prompts  or  menus;  presentation  of  legal  values  information  in 
HELP  displays  is  a  less  attractive,  though  still  viable, 
alternative.  Implementation  of  this  recommendation  will  pro¬ 
vide  particular  benefit  to  relatively  inexperienced  IISS 
users/operators . 

3 .  Tailor  IISS  functions  to  the  needs  of  its  primary  users.  There 
are  few  detailed  recommendations  in  this  area,  since  the  ARI/ 
Synectics  interview  team  did  not  have  an  opportunity  to 
evaluate  user  (GOB  analyst)  requirements  to  any  great  degree. 

It  is  apparent,  however,  that  IISS  provides  little  in  the  way 
of  tailored  capabilities,  other  than  the  content  and  struc¬ 
ture  of  the  order-of-battle  data  bases  themselves.  IISS 
functions  should  reflect  the  mission,  responsibilities,  and 
desires  of  its  primary  users.  As  yet,  there  is  almost  no 
evidence  that  this  has  been  accomplished.  Identification 

of  these  functions  will  require  establishment  of  a  dialogue 
among  command  (operational)  personnel,  intelligence  analysts, 
and  system  designers/developers/proponents. 

4 .  Establish  and  rigorously  enforce  consistency  Jr»  system  ter¬ 
minology,  structure,  and  abbreviation  conventi _  ,s.  IISS  is 
not  tremendously  deficient  in  this  area.  The  few  areas  for 
potential  improvement  are  particularly  aggravating,  since 
the  system  is  in  general  quite  good.  The  existing  incon¬ 
sistencies  are  a  wholly  unnecessary  source  of  user/operator 
error,  inefficiency,  and  frustration. 


More  fully  exploit  the  capabilities  of  the  SU  1652  terminal. 
Adding  selective  highlighting  capabilities,  graphics  displays, 
and  a  more  flexible  exploitation  of  the  dual-screen  display 
potential  are  important  areas  for  IISS  development. 
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Increase  system  retrieval  efficiency ♦  The  IISS  can  take  3 0 
minutes  or  more  to  complete  a  search  through  a  2000  record 
data  base.  This  retrieval  time  needs  to  be  reduced  for  an 
order  of  magnitude  or  more.  Otherwise,  the  IISS  will  be 
extremely  frustrating  for  users/operators  attempting  to 
accommodate  to  the  requirements  imposed  by  high-threat  or 
wartime  tactical  missions. 

Increase  error  message  intelligibility  and  information  content. 
Current  error  messages  and  formats  presume  too  much  user/ 
operator  knowledge  of  ADP  operations  and  data  base  structure. 
They  are  also  too  weakly  linked  to  the  actual  errors  which 
have  occurred. 
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APPENDIX  A 


transaction  FEATURE  ANALYSES  OF  iiss 


1.  CONTROL  METHODS 


1.1  Command  Languages 


Transaction  Feature.  Man-Machine  Interface. 

Description.  The  Man-Machine  Interface  of  IISS  simplifies  the 
specification  of  IISS  commands.  The  user/operator  is  not  required 
to  commit  all  of  the  commands  to  memory,  but  is  presented  with  a 
menu  or  lisc  of  the  possible  commands  in  system  displays.  The 
Man-Machine  Interface  also  provides  prompts  for  data  entry. 

Behavioral  Implications .  The  memory  burden  on  IISS  users/opera¬ 
tors  is  greatly  reduced. 

Transactional  Implications.  Because  responses  to  Man-Machine 
Interface  displays  are  translated  into  GIM-II  of  DEC  system 
monitor  commands,  there  is  little  or  no  impact  on  system  respon¬ 
siveness,  processing  speed,  or  system  accuracy. 

Consequences .  The  system  is  easier  for  the  user/operator  to  use 
than  if  a  pure  command  language  were  used.  Users/operators  who 
are  experienced  in  GIM-II  grammar  and  syntax  can  use  that  lan¬ 
guage  to  increase  command  efficiency. 

Recommended  Resolution.  None  required,  except  as  indicated  in 
other  Transaction  Feature  Analyses. 

Transaction  Feature.  GIM-II  command  language. 

Description.  The  GIM-II  command  language  is  an  extremely  power¬ 
ful  one.  It  permits  the  IISS  user /operator  to  perform  almost  all 
of  the  storage  and  retrieval  operations  which  could  possibly  be 
required  with  order-of-battle  data. 

Behavioral  Implication.  The  IISS  user/operator  is  not  constrained 
in  the  range  of  storage  or  retrieval  operations  which  cam  be  per¬ 
formed  with  IISS.  This  reduces  the  frustration  of  users/operators, 
particularly  the  more  ambitious  and  experienced  ones. 

Transactional  Implications.  The  power  and  flexibility  .of  the  GIM-II 
language  reduces  the  need  for  complicated  specialized  programming 
to  support  required  'IISS. functions.  The  format  structure  of  the 
language  makes  it  relatively  easy  to  "front  end."  This  permits  the 
establirhment  of  simplified  command  entry  procedures  such  as  the 
Man-Machine  Interface  currently  used  in  IISS. 

Consequences .  Battlefield  commanders  will  not  be  significantly 
constrained  in  the  range  of  requests  they  can  make  for  extractions 
from  the  order-of-battle  data  bases.  Users/operators  will  be 
pleased  with  the  flexibility  afforded  by  the  language. 
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Recommended  Resolution.  None  required. 

Transaction  Feature.  Execution  of  II SS  commends  without  resorting 
to  GIM-II  language. 

Description.  In  most  cases,  the  IISS  user/operator  can  perform 
functions  from  either  the  MMI  mode  or  from  within  the  GIM-II 
language.  There  are,  however,  two  capabilities  which  can  only 
be  executed  from  the  GIM-II  language  mode.  "  ~ - 

1.  Full  specification  of  report  formats. 

2.  Conditional  retrievals  from  TACOB.data  bases. 

Behavioral  Implications.  The  memory  burden  imposed  by  knowing  the 
GIM-II  language  command  grammar  and  syntax  may  prevent  less  exper¬ 
ienced  users/operators  from  performing  required  system  activities. 

Transactional  Implications.  The  users/operators  are  likely  to  make 
errors  in  attempting  to  use  command  methods  with  which  they  are  not 
intimately  familiar.  They  may  not  be  able  to  perform  their  assigned 
tasks. 

Consequences  of  the  Problem.  Intelligence  reports  and  summaries 
may  be  delayed. 

\ 

Recommended  Resolution.  Prepare  and  incorporate  MMI  screens  to 
enable  users/operators  to  perform  all  functions  currently  acces¬ 
sible  via  the  GIM-II  language  operating  mode. 


1.2  Menus 

*  Transaction  Feature.  Use  of  menus  in  IISS. 

Description.  The  MASTER  MENU  and  GIM  MENU  of  IISS  provide  the 
user/operator  with  a  convenient  method  for  selecting  among  major 
IISS  processing  options.  Switch  options  on  Man-Machine  Interface 
forms  also  provide  menu-like  features. 

Behavioral  Implications.  The  memory  burden  on  users/operators  is 
greatly  reduced.  Users/operators  cure  presented  with  only  those 
processing  options  which  are  valid  at  any  point  in  system  opera¬ 
tions. 

Transactional  Implications.  System  operations  are  not  impaired 
in  any  way  by  the  inclusion  of  menus  in  IISS  interaction. 

Consequences .  The  memory  burden  on  IISS  users/operators  is 
minimized.  Users/operators  can  proceed  through  sequences  of 
IISS  processing  activities  in  a  logical,  "decision  tree," 
fashion. 

Recommended  Resolution .  None  required,  except  as  indicated  in 
other  Transaction  Feature  Analyses. 
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Transaction  Feature.  Amount  of  information  in  MENU  displays. 


Description.  Both  the  MASTER  MENU  (Figure  1)  and  the  G1M  MENU 
(Figure  8)  indicate  available  options  by  listing  brief  terms 
or  abbreviations  for  those  options. 

Behavioral  implications.  The  user/operator  must  remember  the  mean¬ 
ing  of  the  terse  option  descriptions.  This  poses  an  unnecessary 
memory  loading  on  the  users/operators  of  the  system. 

Transactional  implications .  Failing  to  recall  the  meaning  of  the 
terse  prompts  may  result  in  the  user/operator  selecting  an  inap¬ 
propriate  item  from  the  menus,  or  in  the  necessity  for  looking 
up  the  meanings  of  prompts  in  reference  documentation. 

Consequences  of  the  Problem.  Delivery  of  critical  intelligence 
information  may  be  delayed. 

Recommended  Resolution .  Make  the  option  descriptions  more  informa¬ 
tive.  Possible  display  configurations  for  the  MASTER  MENU  and  the 
GIM  MENU  appear  in  Figures  A-l  and  A-2,  respectively.  Note  that 
these  menus  presume  the  use  of  a  light  pen  for  option  selection. 
Light-penning  the  "RETREIVE  OR  MODIFY  ORDER-OF-BATTLE  DATA”  option 
from  the  GIM  MENU  would  result  in  a  display  like  the  one  in  Figure 
A-3.  Selecting  the  "INPUT  ORDER-OF-BATTLE  DATA"  would  result  in 
the  display  like  the  one  in  Figure  A-4. 


Transaction  Feature.  Preparation  of  commands  for  "START  DEVICE," 
"USER  MESSAGE,"  "BULK  DATA  TRANSFER,"  and  "REMOTE  JOB  ENTRY. 

Description.  Command  specification  for  these  four  IISS  functions  is 
currently  accomplished  by  keying  in  "switches"  which  are  listed 
at  the  bottom  of  the  corresponding  MMI  "form."  (See  Figures  9,  13 
and  14;  as  well  as  subsection  1.1  in  the  "Analysis"  section  of 
this  report. ) 

Behavioral  Implications .  The  user/operator  must  remember  the  func¬ 
tion  of  each  of  the  "switches,"  as  well  as  procedural  model  to  be 
followed  in  filling  out  the  MMI  forms.  This  places  am  unnecessary 
memory  burden  on  the  user/operator. 

Transactional  Implications .  Time  to  complete  a  command  specification 
may  be  increased  by  the  'necessity  for  referring  to  hard  copy  docu¬ 
ments.  The  probability  of  error  in  command  specification  is 
increased  by  the  lack  of'  information  on  switch  function  and  the 
absence  of  a  procedural  context  for  translating  user  intent  into 
system  commands.  This  situation  has  implications  for  each  of  the 
four  affected  functions: 

Separate  consequences  are  associated  with  each  IISS  option: 

START  DEVICE — the  user  may  be  unable  to  attach  a  parti-  / 
cular  device  to  the  IISS  system,  or  the  attachment  of 
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the  device  may  be  delayed.  This  could  result  in  a 
failure  of  a  qualified,  urgently  needed  analyst  being 
denied  or  delayed  access  to  IXSS. 

2.  USER  MESSAGE — the  user  may  be  unable  to  send  a  message 
to  a  colleague,  or  transmission  of  the  message  may  be 
delayed  while  the  user/operator  ascertains  how  to  enter 
user  message  commands. 

3.  BULK  DATA  TRANSFER — the  user  may  not  be  able  to  transmit 
or  receive  large  quantities  of  data  necessary  for  accu¬ 
rate  intelligence  analysis,  or  transmission  of  receipt 
may  be  delayed. 

4.  REMOTE  JOB  ENTRY — the  user  may  be  unable  to  submit  batch 
jobs  to  the  EUCOM  AIDES  H-6000,  or  the  submission  may  be 
delayed. 

Consequences  of  the  Problem.  Each  of  the  transactional  implications 
mentioned  above  may  delay  production  of  vital  intelligence  reports. 
Command  personnel  may  thus  be  deprived  of  data  required  for  battle¬ 
field  decisions. 

Recommended  Resolution.  The  command  specification  for  each  of  the 
four  functions  should  be  broken  into  logical  steps,  so  that  a  con¬ 
sistent  set  of  procedures  can  be  defined  for  each  option.  Alter¬ 
natives  in  the  command  specification  should  be  presented  to  the 
user/operator  in  the  form  of  menus.  A  candidate  specification 
sequence  for  the  BULK  DATA  TRANSFER  option  appears  in  Figure  A-5. 

The  level  of  detail  in  the  available  IISS  documentation  does  not 
permit  an  exact  assessment  of  the  result  of  the  use  of  the  various 
command  "switches;"  thus  Figure  A-5  may  not  be  an  accurate  portrayal 
of  the  most  appropriate  command  sequence.  It  is,  however,  an  illus¬ 
tration  of  the  kind  of  sequenced  command  entry  process  which  would 
reduce  the  complexity  of  the  BDT  command  specification  process  for 
the  IISS  users. 

Following  a  command  sequence  like  that  implied  in  Figure  A-5  might 
entail  a  series  of  menus  like  those  depicted  in  Figure  a-6. 

Again,  this  example  may  be  incorrect  given  the  actual  function  of 
the  IISS  "switches,"  but  it  does  illustrate,  in  general,  how  the 
command  specification  might  be  performed  in  a  revised  IISS  system. 


Transaction  Feature ~  Specification  of  RJE  commands  for  the  EUCOM. 
AIDES  H-6000. 

Description.  IISS  provides  the  user/operator  with  the  capability  to 
access  the  Remote  Job  Entry  (rje)  capability  of  the  EUCOM  AIDES 
Honeywell  H-6000-computers.  This  capability  is  accessed  through 
the  MASTER  MENU  or  TELETYPE  modes  of  IISS.  Using  the  RJE  option. 


Figure  A-5.  Candidate  Bulk  Data  Transfer  Command  Specification  Sequence. 
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IS  THE  SOURCE  FOR  THIS  BULK  DATA  TRANSFER: 

1 .  (US)ER  INPUT  FROM  YOUR  TERMINAL 

2.  (OI)SK  FILE 

3.  (TA)PE  FILE 


ENTER  THE  NUMBER  OR  LETTERS  IN  "(  J"  TO  IDENTIFY  THE 
SOURCE  OF  DATA  — >  01 


o 


ENTER  THE  NAME  OF  THE  DISK  FILE  TO  SERVE  AS  THE  SOURCE 
FOR  THE  BULK  DATA  TRANSFER.  THE  FILE  FORMAT  IS: 

tnnn.mrwi  «f11ename».«f11e  catalog»  ;«vers1on 
number» 

where 

[nnn.mnnj  ■  UIC  number  such  as:  [1M.7B]  -optional. 

If  not  Included,  default  Is  user  l.d. 

«F11ename»  ■  name  of  the  file  (e.g.,  "DATA") 

«F11e  eatalog»  »  catalog  name  (i.g.,  "DAT") 

«Vers1on  number»  -  version  of  the  file  (e.g.,  "12")— 
optional;  If  not  Included 

FOR  THE  EXAMPLES  GIVEN  ABOVE,  THE  FILE  SPECIFICATION  WOULD 
BE:  (1M,7P]DATA.0AT;12 

ENTER  FILE  SPECIFICATION — >{123,87]  INTEL. FRM 


o 


ENTER  THE  BLOCK  SIZE  FOR  OUTPUT  FILE  * [123,87] INTEL. FRM 


o 


OTHER  DISK  FILE  SPECIFICATIONS 


Figure  A-6.  Example  of  Menu-Oriented  BDT  Command  Specification  Sequence. 
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the  user/operator  describes  the  characteristics  of  input  and  output 
files.  To  actually  define  the  requirements  for  the  Remote  Job  Entry 
however/  the  user  must  be  familiar  with  the  H-6000  job  control  lan¬ 
guage  (JCL) . 

Behavioral  Implications.  The  requirement  to  learn  and  recall  the 
H-6000  JCL  imposes  a  significant  memory  burden  on  the  IISS  user/ 
operator.  The  project  team  did  not  have  an  opportunity  to  evaluate 
the  H-6000  JCL,  but  it  is  unlikely  that  its  grammatical  and  syntactic 
structures  are  similar  to  those  of  IISS.  Thus,  there  are  likely  to 
be  negative  transfer  effects  imposed  on  the  user/operator. 


Transactional  Implications.  The  user/operator  may  fail  to  specify 
JCL  correctly,  thereby  receiving  erroneous  output  (or  no  output) 
from  the  EUCOM  AIDES  computer. 

Consequence  of  the  problem.  The  intelligence  analyst  may  receive 
erroneous  information  because  of  unfamiliarity  with  the  H-6000 
JCL,  thus  increasing  the  probability  that  the  battlefield  commander 
will  receive  erroneous  information  about  the  disposition  and/or 
strength  of  opposing  forces.  Even  if  the  output  is  correct,  delays 
caused  by  "trial  and  error"  specification  of  H-6000  JCL  can  delay 
delivery  of  critical  intelligence  information  to  the  commander. 

Recommended  Resol ution.  At  least  two  features  would  greatly  enhance 
the  utility  of  the  RJE  option  to  the  IISS  users: 

1.  Provide  a  "front  end"  in  IISS  to  create  H-6000  JCL.  This 
would  involve  "leading"  the  user ' operator  through  JCL 
specification,  and  would  entail  providing  informative 
prompts  and  information  on  legal  values.  The  "front  end" 
would  also  query  the  user/operator  about  the  characteristics 
of  the  input  file  to  be  operated  on  by  the  H-6000  batch 
routines. 

2 .  Provide  a  library  of  frequently  used  H-6000  JCL  "sets. " 

This  would  eliminate  the  necessity  for  typing  in  the  JCL 
command  sets  for  batch  programs  which  IISS  user/operators 
employ  regularly.  To  use  on  existing  JCL  command  file,  the 
user/operator  would  merely  use  a  "front  end"  such  as  that 
described  in  '1'  (above)  to  specify  the  file  parameters 
and  processing  options  associated  with  that  batch  run. 


Transactional  feature.  Selection  of  options  from  the  MASTER  MENU  and 
the  GIM-II  MENU.  ' 


$ 
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Description.  To  select  options  from  either  the  MASTER  MENU  or  the  j 
GIM-II  MENU,  the  IISS  user  places  the  light  pen  tip  over  any  portion  j 
of  the  term  or  phase  denoting  the  desired  option.  The  terminal  | 
"beeps"  to  indicate  that  the  light  pen  is  positioned  over  a  valid  3 
entry.  The  user  must  then  press  the  SEND  key  to  enter  the  selection  | 
into  the  IISS  system.  If  the  user  is  selecting  the  GIM-II  MENU  from  | 
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the  MASTER  MENU,  the  light  pen  is  used  for  two  selections  in  a  row? 
otherwise  the  user  enters  commands  and  data  using  the  SU  1652  ter¬ 
minal  keyboard. 

Behavioral  Implications.  The  user  must  Icoate  the  light  pen,  posi¬ 
tion  it  accurately,  note  the  terminal  feedback  indicating  appropriate 
positioning,  and  then  press  the  SEND  key  to  enter  the  selection. 

This  requires  the  use  of  two  different  command  modes,  each  of  which 
requires  the  use  of  different  kinesthetic  and  hand-eye  cues. 

Subsequent  interactions  require  that  the  user  locate  the  light  pen 
clip,  place  the  light  pen  there,  and  then  prepare,  to  enter  data  or 
commands  from  the  keyboard. 

Transactional  Implications.  The  user  is  required  to  complete  many 
actions  which  are  not  necessary  for  efficient  selection  of  MASTER 
MENU  and  GIM-II  MENU  options.  This  may  slow  users  down  during  high- 
stress  operations. 

Consequences  of  the  Problem.  The  user/operator  may  become  frus¬ 
trated  with  the  inherent  inefficiency  of  the  system  interaction, 
increasing  the  liklihood  that  users/operators  will  react  negatively 
to  the  use  of  the  system.  The  inefficiency  of  the  process  may  also 
slow  down  interaction  with  the  system,  causing  performance  and 
delivery  of  important  intelligence  information  to  be  delayed. 

Recommended  Solution.  One  minor  palliative  would  be  to  enable  the 
user/operator  to  enter  the  SEND  command  without  using  the  keyboard. 
This  could  be  accomplished  in  one  of  two  ways: 

1.  Use  a  depressible  tip  or  button  on  the  light  pen  to  pro¬ 
vide  a  SEND  signal. 

2.  Provide  a  SEND  field  on  the  menu  displays  which  permits 
the  user  to  light-pen  the  defined  area  of  the  screen  to 
select  the  SEND  command. 

Either  of  these  options  will  make  the  interaction  somewhat  smoother, 
but  will  do  nothing  to  alleviate  the  major  behavioral  discontinuities 
resulting  from  the  use  of  two  command  methods. 

A  more  suitable  resolution  would  be  to  provide  for  keyboard  selection 
of  menu  options.  This  solution  might  be  implemented  for  the  MASTER 
MENU  as  indicated  'in  Figure  A-7.  Instead  of  light-penning  the  desired 
option,  the  user  would  simply  enter  the  number  or  letters  associated 
with  the  desired  option,  and  then  press  the  SEND  key.  To  select  the 
USER  MESSAGE  option)  therefore,  the  user  would  enter  either  "6”  or 
"US." 

The  GIM-II  MENU  presents  a  more  difficult  problem,  since  the  menu 
selection  process  is  (or  can  be)  a  two-step  process.  It  would  be 
possible,  of  course,  to  place  all  of  the  options  on  a  single  menu, 
but  this  would  result  in  a  somewhat  cluttered  menu.  A  better  solu¬ 
tion  might  be  to  break  the  menu  into  two  parts  when  necessary.  The 


1. 

(STA)RT  DEVICE 

8. 

-(GI  )M 

2. 

(STO)P  DEVICE 

9. 

(TS)S 

3. 

(WH)0. 

10. 

(BD)T 

4. 

(HE)LP 

n. 

{RJ  )E 

5. 

(MA)RK 

12. 

(IN)ANAL 

6. 

{US)ER  MESSAGE 

13. 

(SA)NITIZER 

7. 

(PL)OT 

14. 

(TE)LETYPE 

SELECT  NUMBER  OR  LETTERS  IN  "(  )"  FOR  DESIRED 
V  OPTION— > 


Figure  A-7.  Recommended  Change  in  Option  Selection  for  the  IISS  MASTER  MENU. 
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two  parts  of  the  GIM-II  MENU  are  illustrated  in  Figure  A-8.  Selection 
of  one  of  the  first  three  options  in  the  redesigned  GIM-II  MENU  would 
have  the  same  effect  as  in  current  IISS  operations — the  appropriate 
menu  or  prompt  appears.  Selecting  the  "analysis"  or  "input"  options 
would  result  in  the  appearance  of  a  new  menu,  such  as  that  appearing 
at  the  bottom  of  Figure  A-8.  The  user/operator  can  then  select  the 
file  desiraa. 


1 .3  Function  Keys 


Transaction  Feature.  Use  cf.SU  1652  function  keys  in  IISS  operations. 

Description.  The  editing  and  supplementary  operation  fixed  function 
keys  of  the  SU  1652  Display  Terminal  are  effectively  incorporated  in 
IISS  operations.  Commonly  used  editing  and  other  functions  are  thus 
employed  consistently.  Labels  on  the  fixed  function  keys  provide 
constant  prompts  to  the  IISS  user/operator. 

Behavioral  Implications .  Memory  loading  is  considerably  reduced. 

Error  liklihood  is  reduced  because  of  the  consistent  position  and 
labeling  of  fixed  function  keys. 

Transactional  Implications.  Use  of  intelligence  terminal  functions 
increases  the  efficiency  of  main  computer  operations. 

Consequences .  Users/operators  are  less  likely  to  make  errors. 
Battlefield  commanders  are  more  likely  to  receive  on-time  informa¬ 
tion,  and  are  less  likely  to  receive  erroneous  data. 

Recommended  Resolution.  None  required,  except  as  noted  in  other 
Transaction  Feature  Analyses. 


Transaction  Feature.  Use  of  variable  function  keys  of  the  SU  1652 
terminal . 

Description .  Several  important  IISS  functions  and  subfunctions  are 
accessed  through  the  use  of  SU  1652  variable  function  keys.  Since 
the  function  of  individual  keys  is  not  changed,  these  have  the  same 
advantages  as  fixed  function  keys  for  experienced  IISS  users/operators. 
The  lighting  behind  the  key  label  areas  allows  an  indication  of  what 
variable  function  key3  are  active  at  any  point  in  IISS  operations. 

Behavioral  Implications .  The  memory  burden  on  IISS  users/operators 
is  significantly  reduced.  The  labeling  in  the  SU  1652  key  label 
areas  provides  constant  prompts,  and  the  lighting  behind  the  label¬ 
ing  assures  that  usors/operators  will  not  accidentally  attempt  to 
use  function  keys  which  are  not  active. 

Transactional  Implications.  The  use  of  variable  function  keys 
reduces  the  number  of  keystrokes  required  for  commend  selection, 
thereby  reducing  command  specification.  The  prompting  and  "active 
current  option"  features  of  the  variable  function  keys  reduces  the 
probability  of  user/operator  errors. 
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GIM  MENU 


1.  (GI)M  LANGUAGE 

2.  (UT)M-GEO  CONVERSION 

3.  (RE)PORTW  WRITER 

4.  (AN)ALYSIS  OF  TACOB  DATA 

5.  (IN) PUT  TO  TACOB  DATA  BASE 

SELECT  NUMBER  OR  LETTERS  IN  "(  )"  FOR  DESIRED 
OPTION-— > 

< -  -  ^ 


f  ANALYSIS  OF  TACOB  DATA  FILES 

AVAILABLE 

AVAILABLE  TACOB  FILES: 


1. 

(EU)NITS 

8. 

(ACTI)VN 

2. 

(AU)NTF 

9. 

(ACTF)  ,  * 

3. 

(EO)BF 

TO. 

(PL)ATF 

\ 

4. 

(PE)RSNF 

n. 

(ES)YSF 

5. 

(RI)IF 

12. 

(MS)LF 

6. 

(IN)STF 

13. 

(PP)TGT 

7.\ 

(AR)FLDF 

14. 

(RW)YF 

SELECT  NUMBER  OR  LETTERS  IN  "(  )"  FOR  DESIRED  1 

v  OPTION— ■  J 


'igure  A-8.  Recommended  Changes  in  Option  Selection  for  the  IZSS  GIM-II  MENU. 


Consequences.  Throughput  of  intelligence  data  processing  is  increased. 
Battlefield  commanders  will  receive  more  timely  and  accurate  intelli¬ 
gence  information.  Users/operators  will  be  more  satisfied  with  the 
characteristics  of  user/system  interaction. 

Recommended  Resolution.  None  required,  except  as  noted  in  other 
Transaction  Feature  Analyses. 


Transaction  Feature.  Selection  of  appropriate  function  key. 

Description.  Throughout  IISS  processing,  the  user/operator  is  required 
to  use  various  function  keys  to  command  certain  system  operations. 

These  function  keys  are  rather  tersely  labeled.  All  fixed  function 
keys  are  operative  at  any  point  in  IISS  operations,  while  the  vari¬ 
able  function  key  labels  are  lit  only  when  that  particular  option  is 
allowed.  There  is  no  information  describing  the  function  of  these 
keys  other  than  that  included  in  the  user's  and  operations  manuals. 

Behavioral  Implications .  The  user/operator  must  remember  the  function 
of  all  VFKs  and  FFKs.  The  brief  descriptors  printed  on  the  keys  or 
key  labels  provide  some  information,  but  the  memory  burden  is  still 
large . 

Transactional  Implications.  The  user/operator  may; 

1.  Be  forced  to  locate  references  for  the  function  key  in 
the  user's  manuals.  This  requires  time. 

2.  Press  the  wrong  function  key,  resulting  in  an  error  or 
interruption  of  the  activity  in  which  the  user/operator 
is  engaged. 

Consequences .  Intelligence  information  required  by  the  battlefield 
commander  may  be  delayed. 

Recommended  Resolution .  Include  HELP  displays  for  FFKs  and  VFKs. 

These  should  be  keyed  to  the  terminal  activity  being  performed  so 
that: 

1.  Only  valid  VFKs  are  listed  on  the  HELP  displays. 

2.  The  user/operator  is  made  aware  of  slight  differences  in 
function  key  Effects  at  different  points  in  system  activity. 
(For  example,  the  NEXT  PAGE  FFK  is  typically  pressed  to 
obtain  the'  next  page  of  a  multi-page  form.  The  user/opera¬ 
tor  should  be  made  aware,  however,  that  pressing  the  NEXT 
PAGE  FFK  when  the  first  page  of  the  SELECTION/RETRIEVAL 
SCREEN  (Figure  24)  will  result  in  display  of  the  POLYGON 
SEARCH  form. ) 
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1 .4  Prompt s /HELPS 


Transaction  Feature.  Field  labels  in  MMI  and  order-o£-battle  data 
retrieval  and  input  forms. 

Description .  MMI  and  data  input/query  forms  contain  mnemonic  field 
labels.  The  user/operator  must  merely  fill  in  the  blanks  to  specify 
performance  of  the  desired  option,  rather  than  having  to  recall  the 
classes  of  information  to  be  entered. 

Behavioral  Implications ■  Memory  loading  for  _IISS  users/operators  is 
significantly  reduced,  since  the  users/operators  do  not  have  to 
remember  the  data  elements  in  addition  to  the  legal  entries  for  each 
data  element. 

Transactional  implications .  Time  to  enter  certain  kinds  of  queries 
and  certain  sets  of  data  is  reduced,  since  the  user/operator  does 
not  have  to  type  in  command  or  data  element  identifiers. 

Consequences .  IISS  throughput  is  increased.  Battlefield  commanders 
will  receive  more  timely  intelligence  information. 

Recommenced  Resolution .  None  required,  except  as  noted  in  other 
Transaction  Feature  Analyses. 


Transaction  Feature.  Labeling  on  function  keys. 

Description.  Fixed  function  keys  have  labeling  directly  on  the  keys. 
Variable  function  keys  have  labeling  in  key  label  areas  beside  each 
key.  These  labels  provide  essentially  constant  prompting  of  IISS 
functions.  The  lighting  associated  with  variable  function  keys 
refines  this  prompting  even  further;  variable  function  key  labels 
are  lit  only  when  the  associated  function  key  is  active. 

Behavioral  Implications .  A  wide  variety  of  IISS  function  prompts 
are  always  available  to  the  IISS  user/operator.  This  reduces  the 
memory  burden  on  the  user/operator  and  allows  the  formation  of  con¬ 
sistent  perceptual  and  motor  behavioral  patterns  associated  with 
particular  intelligence  functions  or  sequences  of  functions. 

Transactional  Implications.  Time  to  perform  IISS  operations  is 
reduced  because  the  -  user/operator  need  not  pause  to  consider  the 
range  of  options  available  at  given  points  in  IISS  operation.  Prob¬ 
ability  of  error  is  'reduced,  since  the  user/operator  is  less  likely 
to  try  to  use  a  function  which  is  not  valid  at  a  particular  point 
in  IISS  operations., 

Consequences .  Battlefield  commanders  will  receive  information  which 
is  more  timely  and  accurate. 

Recommended  Resolution .  None  required,  except  as  noted  in  other 
Transaction  Feature  Analyses. 
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Transaction  Feature.  Obtaining  HELP  information  on  IISS  legal  values 
and  other  information. 

Description.  IISS  provides  only  a  single  HELP  display  (Figure  il) , 
which  provides  a  brief  description  of  the  major  MASTER  MENU  and  TELE¬ 
TYPE  capability  of  the  system.  No  other  HELP  information  is  avail¬ 
able  on-line  (except  for  function  key  labels) .  Explanatory  informa¬ 
tion  is  available  in  hard  copy  but  is  spread  across  several  documents. 

Behavioral  Implications.  For  IISS  procedures  and  legal  values,  infor¬ 
mation  which  is  voluminous  and/or  rarely  used,  the  user/operator  must 
recall  the  document  and  portion  of  the  document  where  the  information 
is  located.  The  requirement  for  such  recollection  entails  a  signif¬ 
icant  memory  burden. 

Transactional  Implications.  Performance  of  IISS  activities  or  entry 
of  data  may  be  delayed  while  the  user/operator  consults  reference 
documents. 

Consequences .  Delivery  of  critical  intelligence  information  will 
be  delayed. 

Recommended  Resolution.  The  best  resolution  is  to  provide  on-line 
HELP  files  (see  page  A-13) .  If  hardware  or  software  resource  con¬ 
straints  prevent  this,  it  will  be  useful  to  provide  an  on-line 
reference  to  sections  of  documents  providing  explanatory  information. 
This  reference  capability  should  be  keyed  to  individual  displays,  so 
that  use r/Oi>era tors  do  not  waste  time  reviewing  an  on-line  table  of 
contents.  The  on-line  referenda  capability  is  schematically  depicted 
in  Figure  A- 9. 


Transaction  Feature.  Presentation  of  HELP  and  assistance  information 
to  IISS  users. 

Description  of  the  Problem.  There  is  only  one  HELP  display  in  IISS 
(see  Figure  11) .  This  display  contains  in  a  very  terse  manner  what 
the  available  system  capabilities  are. 

Behavioral  Implications.  IISS  is  an  extremely  complex  system.  As  such, 
there  are  a  wide  variety  of  functions  and  input  codes  which  have  to  be 
used  by  IISS  intelligence  analysts.  Without  a  wall-conceived  HELP 
capability,  the  complexity  of  the  system  imposes  significant  memory 
burdens  on  its  operators.  They  must  either  commit  all  of  the  infor¬ 
mation  to  memory  or 'refer  to  external  documents  if  their  recall  fails. 

Transactional  Implications.  IISS  does  not  supply  much  help  information 
to  its  users.  This  either  increases  the  probability  of  error  (if  users 
misremember  command  or  data  entry  codes)  or  requires  more  time  (if 
the  user  must  look  up  code  values  in  a  hard  copy  reference) . 

Consequences .  Errors  in  entering  data  may  result  in  contamination  of 
order-of -battle  files,  resulting  in  providing  operational  commanders 
with  incorrect  data  derived  from  subsequent  retrievals  from  the  files. 
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Errors  caused  by  miaremembering  command  codes  may  result  in  providing 
commanders  with  undesired  or  erroneous  information;  they  may  also 
cause  delays  in  commanders'  receipt  of  critical  intelligence  infor¬ 
mation.  The  time  required  to  find  command  or  data  entry  coda  defini¬ 
tions  in  documents  may  also  delay  delivery  of  intelligence  information 
to  battlefield  commanders. 

Recommended  Resolution.  Ideally,  all  necessary  information  on  command 
and  data  entry  codes  should  be  made  available  at  the  user  terminal. 

For  IISS,  HELP  information  should  be  available  for  the  following  kinds 
of  data: 

1.  GIM  command  statements  (see  Appendix  F) . 

2.  Switches  for  MMI  forms  (see  Appendix  G) . 

3.  Legal  value  ranges  and  codes  for  data  entry. 

4.  File  content  and  structure. 

5.  File  record  elements. 

6.  Data  entry  codes. 

7.  SU  1652  operations,  including  FFKs  (see  Appendix  B)  and 
VFKs  (see  Appendix  C) . 

8.  GIM  command  syntax. 

The  HELP  files  and  displays  for  these  classes  of  information  can 
be  simple  or  complex,  depending  on  the  complexity  of  the  structure 
of  the  information.  At  least  three  kinds  of  help  information  struc¬ 
tures  are  potentially  valuable: 

1.  Single-value  HELP  displays  where  the  user/operator  needs 

to  know  only  the  meaning  or  application  of  a  single  com¬ 
mand  mode,  command,  or  data  element.  For  example,  the 
user/operator  may  wish  information  on  the  meaning  of  the 
STCAT  record  element  in  the  EUNITS  file.  To  obtain  the 
information,  the  user/operator  could: 

a.  Type  "H  STCAT" ;  SEND 

b.  Type  "HELP  STCAT";  SEND 

c.  Press  a  HELP  function  key;  type  STCAT;  SEND 

to  receive  the  HELP  display  appearing  in  Figure  A-10. 

2.  Constrained  set  HELP  displays  where  the  user  must  choose 
from  among  a  set  of  available  options.  For  example,  the 
user  might  wish  some  more  detailec  description  of  the 
switches  available  in  the  USER  MESSAGE  form  (Figure  14) . 
Entering  HELP  SWITCHES  would  yield  the  HELP  display 
depicted  in  Figure  A- 11.  More  information  (.if  any  is 
available)  could  be  obtained  by  entering  a  HELP  request 
for  an  individual  switch. 

Hierarchical  HELP  displays,  required  where  the  user  cannot 
or  has'1” not  provided  enough  information  to  limit  the  number 
of  HELP  displays  required  to  less  than  4  or  5.  For  example, 
a  user  who  for  some  reason  did  not  know  anything  about  IISS 
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PAGE  1  OF  1  ^ 

OATA  ELEMENT:  STCAT 

DEFINITION:  STRENGTH  CATEGORY  OF  AN  IDENTIFIED  OR 
UNIDENTIFIED  UNIT 

PARENT  CATEGORY  OF  THE  FOLLOWING  RECORD  ELEMENTS 


*PRSAT . PERSONNEL  ASSIGNED 

*FHSTR . FOXHOLE  STRENGTH 


♦FHDAT . FOXHOLE  DATE 

MULTIVALUED  FIELD;  MORE  THAN  ONE  ENTRY  ALLOWED 

LEGAL  VALUES  ARE: 

*  0 . 


*  N  -  Legal  entries  should  be  defined /  defi- 

*  E  -  nitions  not  included  in  existing 

*  c  -  documentation 

< _ _ J 


Figure  A-10.  HELP  Display  for  Record  Element  STCAT. 


PAGE  1  of 

SWITCH  OPTIONS  FOR  USER  MESSAGE  FORM 

/SI ;n  —  SPECIFIES  SITE  NAME;  n  -  SITE  NUMBER 

/OP  .  CONSOLE  OPERATOR  TO  RECEIVE  COPY  OF  MESSAGE. 

/AL  .  ROUTES  MESSAGES  TO  ALL  USERS  AT  THE  SPECIFIED 

SITE 

/MT  .  SPECIFIES  THAT  MASTER  TERMINAL  IS  TO  RECEIVE 

■MESSAGE 

/RE  .  MESSAGE  TO  BE  RETAINED  FOR  USER  NOT  LOGGED 

ON 


Figure  A-ll.  HELP  Display  for  USER  Message  Form  Switches. 
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operations  (e.g.,  someone  filling  in  for  a  GOB  analyst  who 
is  unavailable  for  some  reason)  might  want  to  review  some 
aspect  of  system  operation  without  knowing  what  to  call 
it.  Such  a  user  could  simply  type  in  HELP,  thereby 
entering  the  series  of  displays  contained  in  Figure  A-12. 
The  series  of  HELP  displays  would  "lead"  the  naive  user  to 
the  correct  set  of  information. 

These  types  of  HELP  displays  would  be  useful  for  each  of  the  eight 

classes  of  information  listed  above. 


Transaction  Feature.  Prompts  and  HELPS  for  FFKs  and  VFKs. 

Description.  All  FFKs  and  many  VFKs  are  active  through  11SS  opera¬ 
tions.  There  is  no  on-screen  indication  of  the  action  of  these  keys, 
nor  of  what  keys  should  be  used  to  what  desifed  ends. 

Behavioral  Implication.  IISS  users/operators  must  recall  the  action 
of  the  FFKs  and  VFKs,  with  only  the  terse  labels  of  the  keys  them¬ 
selves  as  prompts.  This  memory  burden  is  increased  by  the  fact  that 
some  keys  have  subtly  different  actions  depending  on  the  IISS  pro¬ 
cess  being  performed.  For  example,  the  NEXT  PAGE  FFK  ordinarily 
brings  up  the  next  page  of  a  multi-page  message.  When  the  second 
page  of  the  Selection/Retrieval  Screen  is  displayed,  however,  the 
NEXT  PAGE  FFK  yields  the  Polygon  Search  form.  While  this  form  is 
used  primarily  in  retrieval  of  order-of-battle  information,  it  is 
different  in  form  and  function  from  the  rest  of  the  Selection/ 
Retrieval  form  pages. 

Transactional  Implication .  The  user/operator  may  forget  what  com¬ 
mands  must  he  entered  to  perform  desired  IISS  operations.  This  may 
delay  system- related  activities  while  the  user/operator  consults 
reference  manuals. 

Consequences .  Receipt  of  critical  intelligence  information  by 
battlefield  commanders  may  be  delayed. 

Recommended  Resolution.  Provide  HELP  displays  which  explain  in 

detail  the  action  of  FFKs  and  VFKs.  These  HELP  displays  should  be 

keyed  to  the  IISS  processes  being  employed,  so  thatt 

* 

1.  Subtle  differences  in  the  action  of  FFKs  and  VFKs  may 
be  communicated  to  users/operators. 

2 .  Only  information  on  VFKs  which  is  valid  at  particular 
points  in  the  process  will  be  contained  in  HELP  displays. 

Where  a  particular  vfk  or  FFK  is  required  to  complete  an  action,  this 
information  should  be  automatically  presented  to  the  user/operator 
in  the  form  of  an  on-screen  prompt.  For  example,  the  user/operator 
usually  presses  the  appropriate  SEND  key  to  signify  completion  of 
operations.  When  a  JINTACCS  message  has  been  completed,  hov/ever,  the 
user  must  strike  the  END  MSG  VFK.  This  procedure  should  be  indi¬ 
cated  on  the  display  screen  during  JINTACCS  message  creation. 
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Transaction  Feature,  HELP  display  references. 

Description .  The  single  IISS  HELP  display  appears  in  Figure  11.  When 
the  use '-s/operators  require  some  information  about  the  MASTER  MENU  or 
TELETYPE  options,  they  simply  press  the  HELP  VFK  to  receive  the  HELP 
display.  However,  the  HELP  display  is  somewhat  inconsistent  with  the 
available  IISS  processing  options: 

1.  The  HELP  display  includes  a  reference  to  a  HALT  option. 

This  capability  is  not  listed  on  the  MASTER  MENU,  nor  is  it 
discussed  as  one  of  the  TELETYPE  options. 

i.  The  HELP  display  contains  no  reference  to  the  SANITIZER 
option,  which  is  available  from  both  the  MASTER  MENU 
(the  SANITIZER  option)  and  the  TELETYPE  (the  MMU  >  C3L 
option) . 

3.  The  HELP  display  contains  no  reference  to  th*  PLOT  option, 
which  is  also  available  in  both  MASTER  MENU  and  TELETYPE 
modes . 

4.  The  HELP  display  includes  a  reference  to  a  NOTE  option, 
which  is  not  presented  in  the  MASTER  MENU  nor  in  the 
TELETYPE  documentation  in  the  IISS  Users  Manual. 

Behavioral  implications .  The  user/operator  will  have  to  resolve  the 
inconsistencies  between  the  HELP  display  and  the  manifest  capabilities 
of  IISS.  This  will  be  confusing,  and  may  lead  to  hesitancy  on  the  part 
of  users/operators  to  employ  required  capabilities. 

Transactional  Implications.  The  user/operator  may  be  delayed  in  imple¬ 
menting  a  desired  IISS  function. 

Consequences .  Production  of  valuable  intelligence  information.may  be 
delayed. 

Recommended  Re so lution.  HELP  information  and  actual  system  capabilities 
should  be  made  completely  consistent.  HELP  files  should  contain  refer¬ 
ences  to  all  system  capabilities  which  are  at  a  similar  level  of  detail 
and  sophistication.  The  HELP  files  should  contain  no  information  which 
is  not  clearly  specified  as  a  system  capability  (e.g. ,  NOTE?  HALT). 

The  existing  HELP  inconsistencies  are  not  great  deficiencies  currently, 
since  the  presented  IISS  HELP  capabilities  are  so  limited.  Consistency 
will  have  to  be  assured 'if  a  substantial  enhancement  of  system  HELP 
capabilities  is  envisioned. 
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2.  DISPLAY  FORMAT 
2 . 1  Fixed  Alphanumeric  Displays 


Transaction  Feature.  Display  of  geographic  coordinates. 

Description.  Geographic  coordinates  are  displayed  by  IISS  primarily  to 
indicate  the  position  of  units  in  the  TACOB  order-of-battle  files. 

These  coordinates  are  provided  in  one  or  both  of  two  forms: 

1.  Latitude/longitude  (GEO) ,  which  has  the  format: 

ddmms s Adddmms sA 

•  Lat  Lon 

where : 


d  =  degrees  (maximum  of  two  characters  for  latitude; 

maximum  of  three  characters  for  longitude) 
m  =  minutes 
s  =  seconds 

A  *  N  (North)  or  S  (South) 

u 

A  *  E  (East)  or  W  (West) 

Lon 

An  example  of  a  GEO  display  is  354327N0972801E 
2.  Universal  Transverse  Mercator  (UTM) ,  which  has  the  format: 
nnAAAnnnnnnnn 


where : 

\ 

n  ■  numeral 

A  =  alphabetic  character 

The  IISS  documentation  does  not  further  define  the  UTM  format. 

The  IISS  user/operator  is  sometimes  required  to  copy  geographic  coor¬ 
dinates  information  from  one  place  to  another  (as,  for  instance,  in 
UTM/GEO  or  GEO/UTM  conversion) . 

Behavioral  Implications K  The  user/operator  must  break  .the  geographic 
coordinate  into  its  separate  subfields  (e.g.,  dd-mm-ss)  mentally.  The 
probability  of  misreading  the  closely  packed  characters  is  thus  rela¬ 
tively  high. 

Transactional  Implications.  The  user  may  misenter  the  coordinate, 
causing  an  erroneous  indication  of  the  position  of  an  enemy  unit. 
Maximum  discrepancies  between  intended  (actual)  and  erroneously  entered 
GEO  data  are  indicated  in  Table  A-l.  It  should  be  noted  that  the  pro¬ 
bability  of  GEO  data  entry  error  due  to  confusion  with  adjacent  fields 
different  for  the  individual  characters  of  the  GEO  coordinate.  The 
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most  important  determinant  of  the  liklihood  of  error  of  this  sort 
appears  to  be  the  clarity  of  the  perceptual  "boundary"  to  which  the 
affected  GEO  coordinate  character  can  be  compared.  At  least  two  types 
of  boundaries  exist  in  GEO  coordinates: 


Initiation/termination  of  the  GEO  coordinate  strinc 


Alphabetical  characters  designating  latitude  and  longitude 
hemispheres. 


The  closer  a  character  is  to  one  of  these  boundaries,  the  less  likely  a 
character  is  to  be  confused  with  an  adjacent  'one.  Given  this  assess¬ 
ment,  the  character  positions  with  the  highest  probability  of  error 
are: 


1.  The  "ones"  position  of  minutes  for  both  latitude  and 
longitude . 

2.  The  "tens"  position  of  minutes  for  both  latitude  and 
longitude. 

3.  The  "ones"  position  of  degrees  for  longitude. 

Consequences .  Battlefield  commanders  may  receive  one  or  more  of  the 
following  classes  of  erroneous  information: 

1.  Incorrect  positions  of  enemy  units. 

2.  Incorrect  assessments  of  the  rate  of  movement  of  enemy  units. 

3.  Incorrect  listings  of  the  number  and  type  of  enemy  units  with¬ 
in  ri  kilometers  of  a  given  point  (GEO  coordinates  are  entered 
to  indicate  center  point  of  a  circle  search) . 

4.  Incorrect  listing  of  the  number  and  type  of  enemy  units  with¬ 
in  a  region  of  interest  to  the  battlefield  commander  (GEO 
coordinates  are  entered  to  define  a  polygon  search) . 

Such  misinformation  could  severely  affect  the  performance  and  efficiency 
of  a  battlefield  unit. 


Recommended  Resolution.  The  GEO  coordinates  should  be  broken  into  logical 
subgroups  for  display.  If  a  degree  sign  (°)  is  available,  the  following 
coirmonly  accepted  display  format  might  be  used: 

dd°mm' ss"a'  ddd0mm'Ss"A  (exrnple:  35*43'27"N  097°28‘01"E) 

If  the  appropriate  special  characters  are  not  available,  simply  breaking 
the  coordinates  into  subfields  using  common  delimiters  will  be  beneficial: 

dd-mm-ssA  dd-mm-ssA  (example:  35-43-27N  097-28-01E) 
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Transaction  Feature.  Display  of  date  information. 

Description.  IISS  currently  displays  date  information  in  the  following 
format: 

YYMMDD  (example:  810322  for  March  22nd,  1981) 

No  delimiters  are  used  to  separate  the  year,  month,  and  day  subfields. 

Behavioral  Implications ■  The  date  format  is  different  from  those  com¬ 
monly  employed  in  either  civilian  or  military  practice.  This  imposes 
an  unnecessary  memory  burden  on  the  user/operator.  Furthermore,  the  lack 
of  delimiters  creates  problems  in  separating  the  year,  month,  and  day  sub- 
fielas  of  the  date. 

Transactional  Implications.  The  IISS  user/operator  may  misread  the  date. 
Month  and  day  will  be  particularly  easy  to  confuse. 

Consequences .  The  battlefield  commander  may  receive  erroneous  informa¬ 
tion  of  one  or  more  of  the  following  types: 

1.  Date  at  which  information  about  an  enemy  unit  was  last 
updated. 

2.  Date  at  which  an  enemy  unit  received  training. 

3.  Date  at  which  an  enemy  unit  changed  location. 

4.  Date  at  which  enemy  unit  equipment  number  and  type  was  last 
evaluated. 

5.  Date  at  which  enemy  unit  strength  was  last  evaluated. 

6.  Date  at  which  enemy  unit  combat  readiness  was  last  evaluated. 

Recommended  Resolution .  At  a  minimum,  delimiters  should  be  placed  so 
as  to  increase  the  readability  of  the  date  field.  For  example,  dashes 
might  be  used  to  yield  the  following  format: 

YY-MM-DD  (example:  81-03-22,  for  March  22nd,  1981) 

For  maximum  readability  and  decipherability,  however,  disambiguation 
of  the  date  subfields  should  be  maximized  by  converting  the  "month" 
subfield  into  alphabetics.  Furthermore,  the  date  format  should  be 
changed  into  one  more  likely  to  be  familiar  to  IISS  users,  such  as 
that  used  in  the  date-time-group  (DTG) . 


2.2  Variable-Length  Alphanumeric  Displays 

,  Transaction  Feature.  Format  of  index  display. 

Description .  when  using  either  the  GIM-II  MENU  or  GIM-II  LANGUAGE 
methods  for  analysis  of  TACOB  data,  rhe  IISS  user/operator  first 


describes  the  characteristics  of  the  information  to  be  retrieved. 

The  system  then  displays  the  INDEX  LIST  (illustrated,  in  Figure  17). 
The  available  IISS  documentation  makes  no  mention  of  any  method  for 
altering  the  format  of  the  INDEX  LIST.  The  format  of  the  INDEX  LIST 
is  apparently  fixed,  although  the  length  (number  of  items  listed) 
depends  on  the  number  of  "hits"  (records  in  accordance  with  the 
retrieval  specification) . 

Behavioral  Implications,  while  the  information  contained  in  each 
of  the  "records"  on  the  index  list  may  be  intrinsically  of  inter¬ 
est  to  the  IISS  user/ opera tor ,  it  is  often  used  only  to  guide  the 
user/operator  in  selecting  a  particular  item,  for  full  record  dis¬ 
play.  The  information  which  should  be  made  available  to  support 
this  decision  process  will  depend  on  the  intelligence  analysis 
problem  on  which  the  user/operator  is  working.  The  fixed  format  of 
the  INDEX  LIST  may  thus  force  the  user/operator  to  use  inappropriate 
information  for  making  full  record  review  decisions. 

Transactional  Implications.  The  user/operator  may  have  to  review 
several  "full  record"  displays  of  TACOB  information  before  finding 
one  which  weuld  have  been  obvious  if  a  "tailored"  INDEX  LIST  has 
been  available.  An  alternative  would  be  for  the  user/operator  to 
use  the  REPORTW  function  to  generate  formatted  output ,  but  this 
requires  additional  time.  In  either  case,  reaching  the  ultimately 
desired  record  will  require  more  tine  than  with  an  INDEX  LIST  with 
appropriate  contents. 

Consequences.  Critical  intelligence  information  may  be  delayed  in 
reaching  battlefield  commanders.  Moreover,  the  lack  of  appropriate 
information  for  analytic  decision-making  may  lead  to  inappropriate 
intelligence  analysis  in  high-stress  situations. 

Recommended  Resolution.  Provide  IISS  users/operators  with  some 
means  of  quickly  selecting  an  INDEX  LIST  format.  Ideally,  these 
formats  would  be  stored  as  menu-selectable  options,  so  that  indivi¬ 
dually  tailored  INDEX  LIST  configurations  will  be  available  for 
particular  analysis  situations. 


2.3  Graphic  Displays 


Transaction  Feature:  Display  of  results  of  geographically-ordered 
searches. 

Description.  The  results  of  geographically-oriented  searches  are 
currently  available  only  as  textual  listings  of  unit  positions. 

The  PLOT  option  discussed  in  IISS  documentation  is  not  currently 
usable  by  IISS  analysts/users.  No  "on-screen"  graphics  are  pro¬ 
vided. 
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Behavioral  implication* .  Geographic  distribution  of  units  is  best 
represented  graphically.  Examination  of  configurations  of  units 
and  changes  in  these  configurations  over  time  is  best  accomplished 
through  graphic  displays.  Even  if  the  PLOT  capability  were  fully 
implemented  and  usable  by  GOB  analysts,  use  of  a  flatbed  plotter 
for  tentative  analyses  would  be  wasteful. 

Transactional  Implications.  Currently,  users/operators  must  either 
generate  plot3  manually  or  request  that  plots  be  generated  for  them. 
Either  method  requires  more  time  than  would  be  necessary  for  an  on¬ 
screen  plot. 

izr.secuer.ces.  Intelligence  analysis  accuracy  or  timeliness  may 
be  suboptiaum. 


Race. amended  Resolution.  Utilize  the  graphics  capabilities  of  the 
SU  1652  terminal  to  permit  generation  of  on-screen  plots.  Rough 
plots  may  be  generated  even  without  using  the  graphics  capabilities, 
the  80  :<  24  display  screen  can  be  used  to  indicate  position  to  an 
accuracy  sufficient  to  support  many  types  of  analysis,  though  pre¬ 
sentation  of  even  limited  topographical  information  would  be  diffi¬ 
cult. 


2.4  High! ighti ng 


Transaction  Feature.  Highlighting  in  IISS  displays. 

Description*  As  far  as  can  be  determined  from  available  IISS  docu¬ 
mentation,  no  forms  of  selective  highlighting  are  used  to  enhance 
IISS  displays.  The  SU  1652  terminal  has  at  least  the  following 
highlighting  capabilities:  \ 

1 .  Reverse  video . 

2.  Brightness  control  (2  levels). 

3.  Blinking. 

Behavioral  implications .  Selective  highlighting  should  increase 
the  speed  and  accuracy  of  user/operator  identification  of  particularly 
important  data.  Not  using  selective  highlighting  techniques  in  IISS 
makes  it  more  difficult  for  the  users/operators  to  quickly  determine 
what  portions  of  displays  have  the  most  direct  bearing  on  current 
interactive  tasks. 

Transactional  Implications.  Users/operators  will  require  more  time 
to  extract  high-priority  information  from  IISS  displays. 

Consequences.  Iniitation  of  important  intelligence  processes  may 
be  delayed.  Receipt  of  critical  intelligence  information  by  battle¬ 
field  commanders  may  be  delayed. 
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Recormended  Resolution.  Employ  selective  highlighting  in  IISS  in  at 
least  the  foliowing  kinds  of  situations; 

1.  Indicate  what  option  has  been  selected  by  the  light  pen 
prior  to  user/operator  use  of  the  SEND  key.  (Increased 
brightness  recommended.) 

2.  Indicate  receipt  of  user  message.  (Blinking  recommended.) 

3.  Indicate  user-selected  conditions  in  output  (e.g.,  authorized 
equipment  above  a  certain  percentage  of  equipment  on  hand; 
units  within  50  km.  of  a  particular  point) . 

4.  Indicate  erroneous  portions  of  input  strings.  (Reverse  video 
recommended. ) 

5.  Indicate  potentially  erroneous  file  entries  (e.g.,  enemy  unit 
of  a  particular  type  which  has  20  fewer  personnel  than  auth¬ 
orized;  location  and  time  data  indicating  that  a  particular 
unit  has  moved  400  km.  in  less  than  a  day) .  (Increased 
brightness  recommended.) 
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3.  DATA  ENTRY  ASSISTANCE 


3.1  Information  on  Legal  Entries 


Transaction  Feature.  Legal  values  for  order-of-battle  data  entry. 

Description .  Legal  values  for  certain  elements  of  order-of-battle  file 
records  are  not  presented  to  IISS  users/operators.  Some  of  these  legal 
values  are  explicitly  stored  in  GIM-II  edit  dictionaries. 

3e::aviorai  Implications .  IISS  users/operators  must  remember  the  legal 
values  for  all  order-of-battle  data  fields.  If  they  do  not  remember  the 
appropriate  codes,  they  must  look  them  up  in  reference  manuals.  This 
situation  entails  an  unnecessary  memory  burden,  and  may  necessitate  use 
of  an  inefficient  job  aid. 

Transactional  Implications .  Mis remembering  appropriate  input  codes  may 
result  in  detection  of  an  input  error,  necessitating  correction  of  the 
error  before  work  can  continue.  The  user/operator  may  also  enter  legal 
but  incorrect  code,  resulting  in  degraded  data  base  accuracy  or  retrieval 

of  undesired  information. 

Consequences •  Receipt  of  intelligence  information  may  be  delayed 
because  cf  data  entry  errors  or  time  spent  in  locating  legal  value 
information.  Incorrect  intelligence  data  may  be  received  by  battle¬ 
field  commanders  because  of  prior  entry  but  incorrect  data  values. 

Recommended  Resolution.  Present  available  legal  values  which  are 
stored  in  GIM-II  editing  dictionaries.  These  might  be  stored  in  HELP 
files,  but  a  better  alternative  is  to  include  them  in  input  menus. 


Transaction  Features.  Presentation  of  legal  value  information  for  IISS 
option  switches. 

Description.  Two  of  the  option  switches  used  in  IISS  have  a  limited 
number  of  legal  parameter  values  associated  with  them.  These  legal 
values  are  not  displayed  to  IISS  users/operators.  The  relevant  switches 
and  their  associated  legal  values  sets  sure: 

1.  /LB: nn,  indicating  magnetic  tape  labeling  information, 
where  "nn"  may  be: 

a.  BL  =  bypass  label 

b.  SL  =  standard  label 

c.  NL  *  no  label 

2.  IRF;nn,  specifying  the  record  format  for  output  files, 
where  "nn"  may  be: 

a.  VS  =  variable  span 

b.  VB  =  variable  blocked 

c.  F  =  fixed  length 

d.  FB  =  fixed  blocked 
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In  addition  to  those  which  have  fixed  legal  values  sets,  other  switch 
values  may  be  definable  at  system  initialization: 

3.  /BS,  indicating  block  size  for  tape  or  disk  files 

4.  /PR: a,  indicating  message  priority 

5.  /SI: xx,  indicating  site  designation 

6.  /VL : n ,  indicating  volume  label  for  magnetic  tape 

Behavioral  Implication.  Mis remember ing  appropriate  input  codes  may 
res* alt  in  detection  of  an  input  error,  necessitating  correction  of  the 
error  before  work  can  proceed.  The  user/operator  may  also  enter  a 
legal  but  incorrect  code,  resulting  in  unintended  system  processing 
operations. 

Transactional  Implications.  IISS  users/operators  must  remember  the 
.legal  values  for  all  switch  options.  If  they  do  not  remember  the  appro¬ 
priate  codes  or  values,  they  must  look  them  up  in  reference  manuals. 

This  situation  entails  an  unnecessary  memory  burden,  and  may  necessitate 
use  of  an  inefficient  job  aid. 

Consequences .  Receipt  of  intelligence  information  may  be  delayed 
because  of  time  spent  in  correcting  erroneous  switch  specifications. 

Recommended  Resolution .  Present  legal  values  for  switch  options.  These 
might  be  contained  in  HELP  displays,  but  a  better  alternative  is  to 
include  them  in  process  specification  menus. 


Transaction  Feature.  Presentation  of  switch  options. 

Description.  In  the  USER  MESSAGE,  BDT,  and  RJE  forms  (Figures  14,  9, 
and  13  respectively,  the  user/operator  mav  enter  the  option  switch  /FI 
to  indicate  that  the  previous  specification  is  for  a  file  rather  than 
for  a  user  terminal.  This  switch  is  used  to  define  either  the  source 
or  the  destination  of  a  particular  set  of  information.  The  /FI  switch 
option  does  not  appear  on  any  of  the  forms. 

Behavioral  Implications.  Since  the  /FI  switch  does  not  appear  as  a 
listed  option,  it  cannot  serve  as  a  cue  to  the  user/operator. 

Transactional  Implications .  The  user/operator  may  not  .realize  that  file 
specification  is  a  legal  option,  since  the  /FI  switch  is  not  presented 
in  the  options  portion  of  the  display. 

Consequences .  Delivery  of  needed  intelligence  may  be  delayed.  The 
user/operator  may  be  induced  to  use  suboptimum  procedures  for  gathering 
or  transmitting  information,  thus  slowing  the  delivery  of  intelligence 
information. 

Recommended  Resolution.  Include  the  /FI  switch  as  an  option  on  all 
relevant  forms. 


3.2  Unburdening  of  Input 


Transaction  Feature.  Automatic  generation  of  geographic  coordinates. 

Description.  Many  order-of-battle  records  require  the  entry  of  at 
least  tnree  types  of  geographic  location  entries: 

1.  Geographic  (latitude/longitude)  coordinates. 

2.  Universal  Transverse  Mercator  (UTM)  coordinates. 

3.  Military  grid  reference  system. 

i:.-s  users  /ope  r  a  tors  are  required  to  enter  only  one  of  the  first  two 
ty;.e»  of  location.  The  others  are  automatically  generated  by  the 
system . 


3ehavio rai  Implications .  Time  to  enter  location  references  for  order- 
of-battle  data  is  reduced,  because  the  user  is  not  required  to  enter 

functionally  redundant  information . 

rr.insoctlo.ca..  Implications .  Less  time  is  required  to  complete  order-of~ 
hat  tie  record  data  entry.  Probability  of  error  is  reduced,  since  the 
user /opera tor  will  not  be  required  to  calculate  or  transcribe  geo- 
ooordiuutes . 


Consequences .  ilb'i  users/operators  will  not  become  frustrated  by  being 
forced  to  enter  redundant  information.  Battlefield  commanders  wilJ 
receive  more  accurate  and  timely  intelligence  information. 

P.ecomnended  Re  sol  ue  ion  .  None  required,  except  as  noted  m  other  Trans¬ 
action  Feature  Analyses. 


Transaction  feature.  Automatic  entry  of  update  date  (UDATE) . 

Description.  The  date  of  all  updates  to  order-of -battle  records  must 
be  stored  in  the  record.  This  date  is  automatically  assigned  by  IISS 
when  udpates  are  made. 

Behavioral  Implications .  The  user/operator  need  not  enter  date  of  update? 
fewer  keystrokes  are  thus  needed  to  perform  the  update. 

Transactional  Implications .  Less  time  is  required  for  order-of-battle 
record  updates  than  would  be  the  case  if  users/operators  were  required 
to  enter  updates  manually.  The  probability  of  entry  of  erroneous  dates 
is  reduced  to  virtually  zero,  since  it  is  extremely  unlikely  that  IISS 
hardware  and  software  will  make  an  undetected  error  in  automatic  assign¬ 
ment. 

Consequences .  IISS  users/operators  can  update  order-of-battle  records 
more  quickly  than  would  be  the  case  with  manual  update  date  entry. 
Battlefield  commanders  will  receive  more  accurate  and  timely  intel¬ 
ligence  information. 

Recommended  Resolution.  None  required,  except  as  indicated  in  other 
Transaction  Feature  Analyses. 
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Transaction  Feature.  Automatic  generation  of  position  track  for  enemy 
units. 

Description.  Five  locations  and  their  associated  dates  are  stored  for 
all  enemy  units  in  the  IISS  order-of-battle  data  base:  the  current 
location  and  date  and  the  five  previous  ones.  When  a  new  location  and 
date  are  entered,  the  others  are  automatically  "pushed  down"  in  the  list 
of  recent  location  and  time  observations.  The  oldest  stored  location  and 
date  are  automatically  deleted  from  the  data  base. 

Behavioral  Implications.  IISS  users/operators  are  required  to  enter 
only  20%  of  the  keystrokes  which  would  be  required  if  the  locations 
and  dates  used  for  the  position  track  were  altered  manually. 

Transactional  Implications.  Updates  of  enemy  unit  locations  can  occur 
up  to  five  times  faster  than  would  be  required  if  manual  update  methods 
were  employed.  The  probability  of  creation  of  erroneous  position  track 
information  is  greatly  reduced,  because  there  is  no  need  to  manually 
insert  position  and  date  information  into  their  appropriate  storage 
slots. 

Consequences.  Intelligence  throughput  in  IISS  is  increased.  Battlefield 
commanders  will  receive  more  accurate  and  timely  information  on  the  cur¬ 
rent  and  past  locations  of  enemy  forces. 

Recommended  Resolution.  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Retrieval  string  specification. 

Description.  Users/operators  must  use  either  the  MMI  or  GIM-II  language 
procedures  for  retrieving  a  subset  of  information  from  order-of-battle 
data  bases.  There  is  no  way  to  store  these  retrieval  specifications  for 
later  use.  If  a  user/operator  wishes  to  perform  a  particular  retrieval 
every  day  or  every  week,  the  specifications  must  be  entered  at  the  ter¬ 
minal  each  time  the  retrieval  i3  to  be  performed. 

Beha vi oral  Impl ications.  The  lack  of  a  method  for  storing  and  reusing 
retrieval  string  specifications  forces  the  IISS  users/operators  to  per¬ 
form  redundant  operations. 

Transactional  Implies t ions .  Reentry  of  identical  retrieval  specifica¬ 
tions  requires  more  time  than  would  be  the  case  if  there  were  some 
method  for  saving  the  specifications.  Forcing  the  user/operator  to 
enter  identical  specifications  increases  the  probability  of  error. 

Consequences .  Delivery  of  critical  intelligence  information  to  the 
battlefield  commander  may  be  delayed.  Errors  in  retrieval  specifications 
which  are  not  detected  by  the  IISS  users/operators  may  result  in  incon¬ 
sistent  intelligence  products  (i.e.,  analysts  and/or  commanders  may  be 
comparing  information  which  is  supposed  to  have  been  derived  from  the 
same  retrieval  specifications,  but  which  actually  differ  because  of 
errors  in  retrieval  specification) . 


.Recommended  Resolution.  Provide  a  method  for  storing  retrieval  speci¬ 
fications.  This  method  should  include  conventions  for  naming  the 
specifications,  as  well  as  provisions  for  describing  the  form  and  appli¬ 
cation  of  the  specifications  in  IISS  operations. 


Transaction  Feature.  Specification  of  circle  search. 

Descri  ptr  Lon .  The  IISS  users/operators  must  enter  the  center  point  of  a 
circle  search  as  geographic  coordinates.  If  command  personnel  request 
a  circle  search  around  a  named  place  (e.g.,  town,  city,  bridge,  natural 
feature,  promoticot  y)  the  user/operator  must  either  look  up  the  point  in 
1.",  appropriate  reference  or  estimate  the  coordinates  from  the  position 
of  the  named  place  on  a  map.  IISS  contains  no  method  for  converting 
from  place  names  to  geographic  coordinates. 

behavioral  Tr.pl  Mentions.  The  requirement  to  convert  place  names  to 
geogratvuc  coordinates  forces  tne  user/operator  to  alter  frames  of 
reference  in  specifying  the  center  point  of  a  circle  search.  Further¬ 
more,  the  requirement  for  estimating  or  transcription  of  geographic 
coordinates  increases  the  liklihooa  of  error  in  center  point  specifica¬ 
tion. 

Tra.nsactuona i  Implications .  The  user/operator  will  require  more  time 
to  develop  the  center  point  geographic  coordinates  if  those  coordinates 
are  not  stored  in  association  with  place  names  in  IISS  files.  Trans¬ 
cription  of  geographic  coordinates  increases  the  liklihood  that  center 
point  specification  will  be  erroneous. 

Consequences .  Delivery  of  intelligence  information  to  the  commander 
may  be  delayed.  Errors  in  center  point  specification  may  lead  the 
commander  to  be  misinformed  about  the  absolute  and  relative  positions 
of  enemy  units  or.  the  battlefield. 

Recommended  Resolution .  Provide  a  means  for  entering  place  names  as 
the  center  points  of  circle  searches.  For  optimum  utility,  this  capa¬ 
bility  should  include  a  parser  for  user  specifications  of  deviations 
from  named  places.  For  example,  the  user  should  be  able  to  enter  "10 
miles  west  of  Berlin,"  "30  km.  SSW  of  Frankfurt,"  or  "12.3  miles  bear¬ 
ing  276  from  Dusseldorf"  as  valid  specifications  for  circle  search 
center  points.  It  would  probably  be  impossible  for  any  system  config¬ 
uration  similar  to  the  current  IISS  to  store  on-line  all  conceivable 
named  places  in  the  world.  However,  the  tactical  support  emphasis  of 
IISS  will  permit  the  scope  of  place  names  to  be  constrained  somewhat. 
The  focus  of  hostilities  and/or  intelligence  analysis  emphasis  could 
allow  the  users/operatorr,  to  further  delimit  the  geographic  scope  of 
•place  name  requirements.  Place  names  for  a  theatre  could  be  stored  in 
some  nonvolatile  magnetic  medium  (magnetic  tape,  disk  packs),  and  the 
place  name  files  for  appropriate  areas  placed  into  on-line  files,  as 
required. 
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Transaction  Feat ure.  Specification  of  circle  searches. 


Description.  The  user/operator  must  enter  the  geographic  coordinates 
of  the  center  point  of  a  circle  search.  If  the  center  point  of  the 
search  is  the  location  of  a  military  unit  (friendly  or  enemy) ,  the  user/ 
operator  must  retrieve  the  record  for  that  ur.it  and  copy  the  appro¬ 
priate  location  specification  for  the  unit  into  the  circle  search 
retrieval  form. 

Behavioral  Implications .  In  the  situation  described  above,  the  user/ 
operator  probably  has  no  desire  to  perform  a  circle  search  around  somt 
particular  point.  Rather,  the  desire  is  to  locate  all  units  or  instal¬ 
lations  which  are  within  n.  distance  units  from  another  unit.  The  cur¬ 
rent  IISS  procedures  thus  force  the  user/o"erator  to  shift  frames  of 
reference  in  defining  the  circle  search.  The  present  emphasis  is  more 
on  the  geographic  coordinates  than  on  the  spatial  relationships  of 
military  units  and  installations.  Furthermore,  the  need  to  copy 
geographic  coordinates  from  one  place  to  another  increases  the  proba¬ 
bility  of  error.  It  also  requires  more  time  than  a  more  flexible 
method. 

Transactional  Implications.  The  user/operator  may  make  errors  in  tran¬ 
scribing  geographic  coordinates.  The  transcription  process  requires 
time. 


Consequences «  Delivery  of  intelligence  information  to  battlefield  com¬ 
manders  may  be  delayed.  Errors  in  transcribing  geographic  coordinates 
may  lead  the  commander  to  be  misinformed  about  the  status  of  enemy  units 
in  the  vicinity. 

Recommended  Resolution •  Allow  IISS  users/operators  to  enter  unit  I.D.s, 
names,  or  other  identifying  characteristics  as  the  center  points  of 
circle  searches.  The  system  would  then  automatically  retrieve  the  cur¬ 
rent  location  of  the  unit  and  use  this  location  as  the  center  point  of 
the  circle  search.  This  capability  would  be  most  useful  if  the  IISS 
users  had  access  to  the  designation  of  friendly  units. 


Transaction  Feature .  Designating  file  names  for  partially  completed 
JINTACCS  messages. 

Description .  If  the  user/operator  is  interrupted  in  the  process  of 
creating  a  JINTACCS  message,  a  file  name  must  be  provided  for  the  storage 
of  the  partially  completed  message.  There  is  no  assistance  given  to  the 
user/operator  in  generating  this  file  name.  The  file  name  format  is  not 
unique  to  IISS;  rather,  it  is  the  file  name  convention  used  by  the  Digi¬ 
tal  Equipment  Corporation  (DEC),  the  manufacturers  of  the  AN/CYQ-21(V) 
computer  used  in  IISS.  Failure  to  use  this  convention  will  result  in 
an  error. 

Behavioral  implications •  The  user/operator  must  remember  a  fairly 
complex  file  specification  when  the  only  purpose  for  using  this  speci¬ 
fication  is  to  provide  a  basis  for  completing  a  message  whose  generation 
was  interrupted.  It  is  unlikely  that  there  will  be  a  large  number  of 
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partially  completed  messages  at  any  point  in  IXSS  operations.  A  file 
naming  convention  simpler  than  one  used  by  the  DEC  operating  system 
would  reduce  the  memory  burden  on  the  user /opera tor. 

Consequences.  Dissemination  of  important  JINTACCS  messages  may  be 
delayed. 

Recorcnended  Resolution.  Provide  a  standard,  default  file  naming  con¬ 
vention  so  that  the  user/operator  need  no4-  enter  a  file  name  for  a 
partially  completed  message.  For  example,  messages  could  be  entered 
as  "JNaa.MSG" ,  where  "aa"  is  a  two-character  alphabetical  code  assigned 
in  the  order  in  which  the  partially  completed  messages  were  stored. 

It  -a  unlikely  that  a  given  user/operator  would  have  more  than  two  or 
throe  messages  stored  simultaneously,  so  that  users/operaters  would  not 
be  likely  to  be  confused  about  which  messages  are  which.  Note  that  in 
this  method  the  users/operators  would  not  have  to  be  aware  of  the  file 
name  at  all.  Instructing  the  system  to  store  the  messages  in  partially 
completed  form  would  cause  the  system  to  i  utomatically  generate  a  file 
name.  The  user/operator  would  know  that  all  files  of  the  form  "JNnn.MSG" 
in  his  Cl 0  contain  partially  completed  JINTACCS  MESSAGES. 

A  more  elegant  solution  would  be  to  include  ir  IISS  a  "partially  completed 
JINTACCS  message  menu."  This  method  would  list  for  the  user/operator  all 
messages  currently  stored  on  a  selection  menu.  The  menu  would  contain 
information  such  as  message  type,  time  and  date  stored,  addressees, 
etc.  The  user/operator  would  simply  select  one  of  the  messages  from 
the  menu.  Using  this  method,  there  would  be  no  need  for  the  user/operator 
to  be  aware  at  all  of  the  file  name  used  for  message  storage;  and  conven¬ 
tion  convenient  to  the  user/operator  would  be  deleted  from  the  menu 
unless  the  user/operator  explicitly  directed  otherwise. 


3.3  Interrupts  and  Work  Recovery 


Transaction  Feature.  Use  of  dual  screen  display. 

Description .  The  su  1652  terminal  used  as  the  primary  user  terminal  in 
IISS  has  two  display  screens.  When  high  priority  messages  interrupt 
ongoing  intelligence  analysis  activities,  there  is  no  need  to  erase  a 
portion  of  the  display  on  which  the  user/ operator  is  working  to  provide 
notification  of  the  high  priority  event:  notification  of  the  high 
priority  message  is -given  on  the  screen  which  the  user/operator  is  not 
currently  using.  After  dealing  with  the  interruption,  the  user  can 
easily  return  to  the'  processing  on  which  he  or  she  had  been  working. 

Behavioral  Implications .  The  memory  burden  on  users/operators  is 
decreased,  since  there  is  no  need  to  recall  what  activities  were  being 
performed  when  the  interruption  occurred.  Partially  completed  forms, 
menus,  and  input  screens  are  left  undisturbed.  The  user  can  easily 
resume  the  activities  which  were  being  performed  before  the  interrup¬ 
tion.  j 
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Transactional  Implications.  Interruptions  in  user/operator  activities 
have  much  less  impact  on  intelligence  analysis  throughput  than  would 
be  the  case  with  a  less  flexible  display  arrangement. 

Consequences .  Battlefield  commanders  will  receive  timely  intelligence 
information.  Users/operators  will  not  be  frustrated  and  annoyed  by 
receipt  of  high-priority  information;  and  interruptions  of  other  sorts 
of  conversations  with  other  intelligence  analysts,  for  example,  will  not 
be  likely  to  disrupt  ongoing  activities  more  than  is  absolutely  necessary. 

Recommended  Resolution .  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Provision  for  filling  out  partially  completed 
J I NT ACCS  messages. 

Description .  If  the  user/operator  finds  it  necessary  to  interrupt 
completion  of  JINTACCS  messages  while  in  IN  ANAL  mode,  the  message 
can  be  stored  in  a  file.  After  the  user/oeprator  has  dealt  with  the 
interruption,  the  file  can  be  recalled  and  the  message  finished.  This 
feature  is  particularly  useful  in  situations  where  the  user/operator 
must  use  IISS  capabilities  which  employ  both  of  the  SU  1652  display 
screens. 

Behavioral  Implications.  The  user/operator  will  not  have  to  reenter 
information  already  placed  into  the  JINTACCS  message  format. 

Transactional  Implications.  Time  to  complete  JINTACCS  messages  will 
be  kept  to  a  minimum. 

Consequences .  Battlefield  commanders,  other  intelligence  analysts,  and 
personnel  in  other  services  will  receive  JINTACCS  messages  as  soon  as 
possible.  Dissemination  of  information  via  the  JINTACCS  message  route 
will  not  be  delayed  because  IISS  users/oe;?rators  are  forced. to 'reenter 
message  contents. 

Recommended  Resolution .  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Indication  that  there  are  messages  waiting  in 
the  user/operator  message  queue. 

Desrriptoin .  There-is  currently  no  indication  that  a  message  has  been 
received  by  an  IISS  user/operator. 

Behavioral  Implications.  The  user/operator  must  remember  to  period¬ 
ically  check  the  message  queue  to  determine  whether  or  not  messages 
have  been  received.  This  produces  an  unnecessary  memory  burden. 

Transactional  Implications.  The  user/operator  may  fail  to  receive  a 
message  for  some  time  after  it  has  been  received. 
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Consequences .  Important  intelligence  information  or  requests  for 
intelligence  information  may  not  be  received  by  the  user/operator. 

Recommended  Resolution.  Provide  an  on-screen  indication  that  unreviewed 
messages  are  waiting  in  the  user/operator  message  queue.  Provide  some 
means  for  alerting  the  user/operator  to  the  fact  that  the  message  queue 
is  not  empty,  such  as  blinking  a  "messages  waiting"  indicator  for  several 
seconds  out  of  each  minute. 

Transaction  Feature .  Completion  of  entry  of  information  into  partially 
completed  JINTACCS  messages. 

Description .  Creation  of  JINTACCS  messages  is  supported  by  forms  like 
those  depicted  in  Figure  16.  If  the  user/operator  is  interrupted  while 
filling  out  a  JINTACCS  message,  the  partially  completed  message  cam  be 
stored  in  a  file.  The  user  can  then  complete  the  entry  of  information 
into  the  message  at  a  more  convenient  time.  However,  completion  of  the 
partially  completed  JINTACCS  message  is  not  supported  by  the  forms  which 
are  available  when  the  construction  of  the  messages  is  first  initiated. 

Behavioral  Implications .  The  user/operator  is  forced  to  remember  the 
format  of  JINTACCS  messages  in  order  to  complete  them  correctly.  This 
imposes  an  unnecessary  memory  burden  on  the  users/operators. 

Transactional  Implications ,  when  required  to  finish  a  partially  com¬ 
pleted  JINTACCS  message,  the  IISS  user/operator  has  two  options: 

1.  Attempt  to  recall  the  precise  format  of  the  message, 
entering  the  field  labels  of  the  message  as  well  as 
the  data  associated  with  each  of  those  field  labels. 

This  process  will  be  slower  than  "form- supported" 

JINTACCS  message  creation,  since  the  user/operator  is 
required  to  enter  significantly  more  text.  It  also  \ 
greatly  increases  the  likelihood  of  error  in  data  entry, 
because  of  both  the  increased  amount  of  text  required 
and  the  relatively  high  probability  that  the  user/ 
operator  will  not  accurately  remember  the  message  for¬ 
mat. 

2.  Begin  the  construction  of  the  message  all  over  again. 

This  will  clearly  take  time,  since  the  user/operator 
is  entering  information  which  has  been  entered  pre¬ 
viously.  . 

Consequences .  Dissemination  of  important  intelligence  information 
to  battlefield  commanders,  other  members  of  the  intelligence  community 
and  other  services  may  be  delayed. 

Recommended  Resolution.  Permit  the  user  operator  to  use  JINTACCS  forms 
for  completion  of  the  message.  This  capability  would  place  the  infor¬ 
mation  already  stored  in  the  message  suspense  file  into  the  JINTACCS 
form,  allowing  the  user/operator  to  review  the  information  already 
entered  before  completing  the  rest  of  the  message. 
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MESSAGE  COMPOSITION  AIDS 


1  System  Design  Features 


Transaction  Feature.  Data  entry  forms  for  message  composition. 

Description .  IISS  provides  "fill  in  the  blank"  forms  for  the  creation 
of  user  messages  and  JINTACCS  messages. 

Behavioral  Implications .  The  IISS  users/operators  are  not  required  to 
remember  che  format  or  content  of  messages:  the  message  blanks  pre¬ 
sented  in  the  displays  provide  this  information. 

Transactional  I/nplications.  The  probability  of  error  is  reduced,  since 
users/operators  will  not  have  to  recall  the  elements  which  constitute 
each  message.  Speed  of  message  composition  is  increased,  since  the 
users/operators  do  not  have  to  create  valid  formats  during  message  data 
entry  nor  enter  field  names. 

Consequences .  Battlefield  commanders,  other  intelligence  personnel, 
and  personnel  in  other  services  will  receive  intelligence  information 
quickly. 

Recommended  Resolution .  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Completion  of  JINTACCS  messages. 

Description.  IISS  users/operators  currently  complete  JINTACCS  messages 
by  filling  Displayed  "forms”  like  those  depicted  in  Figure  16.  These 
forms  provide  "prompts"  for  each  item  of  information  which  may.be  entered, 
but  provide  no  information  on  legal  values  for  each  data  entry  field. 

Behavioral  Implications.  The  IISS  user/operator  is  forced  to  remember 
the  legal  values  for  all  of  the  fields  in  all  of  the  JINTACCS  messages, 
or  to  look  these  legal  values  up  in  IISS  documents' ion. 

Transactional  Implications.  The  user/operator  may  misremember  the  legal 
values  for  JINTACCS  message  fields,  thus  increasing  the  probability  of 
error.  Referring  to  IISS  documentation  for  legal  values  information 
will  require  more  time  than  if  that  information  were  available  in  ter¬ 
minal  displays.  * 

Consequences .  If  errors'  in  JINTACCS  messages  are  detected,  creation 
of  a  valid  message  will  require  more  time  than  if  legal  values  were 
displayed  at  the  user/operator  terminal.  This  will  delay  receipt  of 
potentially  important  intelligence  information  by  battlefield  commanders, 
other  U.S.  Army  intelligence  personnel,  and/or  other  services.  If  the 
errors  are  not  detected,  the  appropriate  personnel  may  receive  invalid 
information.  Finally,  if  the  IISS  user/operator  must  look  up  legal  values 
in  manuals,  transmission  of  the  message  will  be  delayed. 
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Recommended  Resolution .  At  least  two  resolutions  are  available: 

1.  Providing  a  HELP  capability  keyed  to  the  position  of  the 
cursor  in  the  JINTACCS  message  form  would  allow  the  user/ 
operator  to  access  legal  values  information  for  the  data 
field  of  current  interest.  This  capability  should  be 
coupled  with  a  variable  function  key  permitting  the  user/ 
operator  to  call  up  this  tailored  HELP  information  with 

a  single  keystroke. 

2.  Using  a  menu  approach  to  JINTACCS  message  creation  would 
automatically  provide  legal  values  for  each  field.  If 
either  screen  painting  time  or  display  content  retrieval 
and  transmission  time  (or  the  combination  of  the  two)  is 
too  lengthy,  the  experienced  user/operator  should  have  the 
option  to  inhibit  the  display  of  legal  value  information. 
Where  the  legal  values  list  is  particularly  lengthy,  the 
menu  item  should  be  paged.  A  portion  of  the  JINTACCS  form 
corresponding  to  the  position  of  the  user/operator  in  the 
data  entry  menu  sequence  should  be  displayed  on  the 

SU  1652  display  screen  not  being  used  for  menu  presenta¬ 
tion.  This  will  allow  the  user/oeprator  to  track  the 
progress  and  accuracy  of  JINTACCS  message  formulation. 

The  second  of  these  two  options  is  preferrable  if  screen  painting  time 
and  display  transmission  time  are  sufficiently  brief  (less  than  2 
seconds  or  so) . 


Format  for  Alphanumeric  Messages 


Transaction  Feature.  Selection  of  JINTACCS  message  type. 

\ 

Description .  When  the  IN  ANAL  option  is  selected  from  the  MASTER  MENU, 
the  user/operator  is  presented  with  a  Dissemination  Header  form  (Figure 
22).  This  is  a  "fill-in-the-blanks"  form,  with  no  information  on  legal 
entries. 

Behavioral  implications .  The  user  must  remember  what  input  values  are 
legal  for  each  data  field.  This  represents  an  unnecessary  memory  burden 

Transactional  Implications.  The  user/operator  must  either  look  up  legal 
values  in  reference  manuals,  or  try  to  recall  them  from  memory.  In  the 
latter  case,  the  user/operator  may  make  an  error  which: 

1.  Results  in  an  error "message  and  subsequent  correction  time. 

2.  Results  in  dissemination  of  incorrect  information. 

Consequences ■  Message  addressees  may  receive  incorrect  data.  Dissemina 
tion  of  valuable  intelligence  information  to  battlefield  commanders  may 
be  delayed. 

Recommended  Resolution .  A  definitive  resolution  cannot  be  presented 
here,  because  available  documentation  contained  no  information  about 
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legal  values  for  JINTACCS  messages.  In  general,  however,  a  menu-driven 
message  input  process,  utilizing  both  SU  1652  display  screens,  would  be 
the  preferred  method.  This  method  is  illustrated  in  Figure  A-13,  which 
includes  annotations  which  highlight  design  features  of  the  menu.  Note 
that  the  menu  options  listed  in  Figure  A-13  are  not  those  which  would 
actually  appear;  the  actual  menu  options  depend  on  the  input  require¬ 
ments  and  legal  values  for  JINTACCS  message  formats. 


Transaction  Feature*  Format  of  JINTACCS  messages. 

Poser i otion.  JINTACCS  messages  are,  by  definition,  joint  services 
communication  format  standards.  As  such,  they  must  and  do  accommo¬ 
date  to  the  requirements  of  all  tnree  of  the  major  services.  Some  of 
the  information  contained  in  the  JINTACCS  format  will  not  be  available 
from  U.S.  Army  sources.  Thus,  there  will  be  situations  in  which  Army 
personnel  will  have  no  occasion  to  enter  some  of  the  items  of  informa¬ 
tion  into  certain  JINTACCS  formats.  However,  the  JINTACCS  messages 
forms  stored  by  IISS  present  the  field  labels  for  all  of  the  informa¬ 
tion  which  is  contained  in  the  JINTACCS  format.  The  IISS  user/operator 
is  thus  forced  to  examine  and  evaluate  data  fields  for  which  the  Army 
can  provide  no  information. 

Behavioral  Implications’  In  filling  out  JINTACCS  messages,  the  user/' 
operator  will  be  presented  with  field  labels  for  which  he  or  she  can 
provide  no  valid  information.  This  reduces  the  amount  of  useful 
information  which  can  be  presented  in  a  single  display,  and  may  tempt 
an  inexperienced  user/operator  to  provide  information  which  he  or  she 
is  not  qualified  to  provide. 

Transactional  Implications .  The  requirement  to  review  field  labels 
which  are,  for  Army  purposes,  irrelevant  may  require  more  time  than 
if  only  Army-relevant  information  were  included  in  the  JINTACCS  forms 
or  menu  displays.  Furthermore,  the  probability  that  data  will  be 
entered  into  the  wrong  field  is  increased.  The  user/operator  may 
also  attempt  to  provide  entries  without  adequate  information  (i.e., 
attempt  to  fill  in  a  data  field  which  IISS  users/operators  should  not 
complete) . 

Consequences »  Delays  caused  by  errors  in  filling  out  the  JINTACCS 
forms  may  increase  the  time  required  to  get  valuable  intelligence 
information  to  battlefield  commanders.  The  accuracy  of  data  sets 
based  on  JINTACCS  messages  may  be  compromised  if  personnel  attempt 
to  provide  data  which  they  are  not  qualified  to  generate  or  evaluate. 
This  may  lead  to  data  base  conflicts  and/or  confusion  among  users  of 
these  data  sets. 

* 

Recommended  Resolution .  Prompt  IISS  users/operators  to  enter  that 
information  which  is  available  from  Army  sources.  This  may  be  done 
by  "blanking  out"  extraneous  information  from  data  entry  forms  like 
those  in  Figure  16,  or  bypassing  menu  items  which  deal  with  JINTACCS 
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Figure  A- 13.  Continued 
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data  fields  which  are  irrelevant  to  the  13. S.  Army.  It  may  be  prefer¬ 
able  to  keep  the  "full  JINTACCS  message"  creation  process  as  an  option 
for  situations  where: 

1.  IISS  is  serving  as  a  relay  point  for  indorsation  orig¬ 
inally  generated  by  other  services. 

2.  Personnel  from  other  services  are  interfacing  directly 
with  IISS  users/operators. 

Because  JINTACCS  messages  are  to  be  communicated  and  received  in  a 
standard  format,  IISS  software  will  have  to  "regenerate"  valid 
complete  JINTACCS  formats  prior  to  actual  message  transmission. 

This  implies  the  capability  of  IISS  to  insert  codes  for  "unknown"  or 
"not  applicable"  for  data  fields  which  would  npt  ordinarily  be  pro¬ 
vided  by  IISS  users/operators. 


4.3  Graphic  Messages 


Transaction  Feature.  Preparation  of  graphic  messages. 

Description.  Although  the  SU  1652  terminals  used  in  IISS  are  graphics- 
capable,  there  are  no  provisions  for  sending  graphic  messages  in  IISS. 

Behavioral  Implications.  There  are  situations  in  which  symbols,  maps, 
and  charts  can  convey  information  more  quickly  and  efficiently  than 
text.  The  lack  of  graphics  messages  within  IISS  forces  the  users/ 
operators  into  modes  of  behavior  which  may  not  be  optimum  for  parti¬ 
cular  tasks. 

Transactional  Implications.  The  user/operator  may  require  more  time 
to  compose  a  text  message  which  conveys  the  same  information  as  a 
graphics  message.  The  recipient  of  text  messages  may  literally  have 
to  recreate  the  graphics  message  using  textual  guidance  in  order  to 
interpret  the  information  which  the  sender  is  trying  to  convey. 

Consequences .  Delays  in  generating  and  interpreting  textual  descriptions 
of  graphical  concepts  and  phenomena  may  delay  the  receipt  of  critical 
intelligence  information  by  the  battlefield  commander.  The  lack  of  a 
graphics  message  capability  may  also  mean  that  battlefield  commanders 
cannot  receive  information  in  the  form  which  best  supports  command 
decisions. 

Recommended  Resolution .  Provide  a  mechanism  for  generating  graphics 
messages  on  the  SU  1652  CRT  screens,  as  well  as  protocols  and  pro-  . 
cedures  for  transmitting  those  displays  to  other  IISS  user  nodes. 


5.  DATA  RETRIEVAL  ASSISTANCE 


f  ^  5.1  Query  Method 


Transaction  Feature.  Man-Machine  Interface  query  method. 

Description.  The  IISS  user/operator  specifies  the  desired  character¬ 
istics  of  a  retrieval  from  order-of-battle  data  bases  by  filling  out 
a  selecticn/retrieval  form  (see  Figure  18) .  "Hits"  from  this  retrieval 
are  listed  in  the  Index  List  (see  Figure  17) .  If  users/operators  wish 
to  examine  any  of  the  "hits"  more  closely,  they  simply  light-pen  one 
of  the  items  in  the  list. 

Behavioral  Implications.  The  memory  burden  for  information  retrieval 
tasks  is  decreased,  since  users/operators  are  presented  with  a  list  of 

the  information  record  elements  which  may  be  used  to  define  retrievals. 

Transactional  Implications.  Time  to  specify  order-of-battle  data  base 
retrievals  is  reduced.  Retrievals  may  be  more  accurate,  since  the 
user/operator  is  prompted  with  retrieval  parameters  which  may  not  have 
been  recalled  from  memory. 

Consequences.  Battlefield  commanders  will  receive  information  quickly; 
the  contents  of  intelligence  analyses  will  be  better  tailored  to  the 
commanders '  needs . 

Recommended  Resolution.  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Determination  of  distances  between  two  points. 

\ 

Description.  The  TACOB  data  bases  of  IISS  are  geographically  oriented. 
Since  the  concern  of  tactical  commanders  will  be  with  units  in  the 
field,  rather  than  those  in  garrison,  "one-time"  calculation  of  dis¬ 
tances  between  points  cannot  adequately  support  the  commander's  need 
for  information  about  the  relative  locations  of  enemy  and  friendly 
units.  IISS  contains  no  provisions  for  calculating  distances  between 
points  directly,  even  though  the  circle  and  polygon  search  routines 
must  contain  all  of  the  necessary  mathematical  routines. 

Behavioral  implications.,  IISS  users/operators  are  forced  to  estimate 
or  manually  calculate  distances.  The  IISS  system  could  easily  pro¬ 
vide  this  capability* 

Transactional  Implications.  The  IISS  users/operators  may  make  errors  in 
estimation  or  manual  distance  calculation. 

Consequences .  I-iSS  users/operators  may  be  unable  to  provide  accurate 
information  on  distances  to  battlefield  commanders.  The  time  required 
to  manually  calculate  distances  may  delay  communication  of  this  infor¬ 
mation  to  the  commanders . 
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Recommended  Resolution.  Provide  technique#  for  calculating  distances 
in  IISS.  Different  types  of  distance  calculations,  varying  in  complexity, 
might  be  provided,  including: 

1.  Point-to-point  distance  calculations,  in  which  the  user/ 
operator  would  enter  two  sets  of  coordinates,  and  the  system 
would  return  a  distance  in  appropriate  (and  user-selectable) 
measurement  scales.  This  feature  would  be  more  useful  if 
the  user/operator  could  enter  the  name  of  a  unit  instead  of 
specifying  its  coordinate  location.  The  system  would  then 
automatically  retrieve  the  most  reoent  reported  location  of 
the  unit  and  use  that  value  in  its  distance  calculations. 

Entry  of  place  names  as  an  alternative  to  geocoordinate  or 
unit  specification  would  also  enhance  this  capability. 

2.  Route  distance  calculations,  in  which  the  user  would  specify 

a  route  as  a  series  of  connected  points.  The  sytem  would  then 
calculate  the  total  distance  along  a  route.  This  capability 
would  be  particularly  useful  where  terrain  and  transportation 
system  characteristics  would  not  permit  ground  units  to  travel 
in  straight  lines. 

Specification  of  the  route  would  be  simplified  if  the  user/ 
operator  could  indicate  the  route  on  a  map,  rather  than  typ¬ 
ing  in  a  series  of  geocoordinate,  unit,  or  place  name  specifi¬ 
cations.  Inclusion  of  on-line  cartographic  information  which 
permits  the  IISS  to  generate  maps  on  the  users/operators  CRT 
screens  is  likely  beyond  the  capabilities  of  the  current  IISS 
hardware  configuration.  System  enhancements  to  provide  such 
a  capability  would  probably  be  extremely  expensive,  requiring 
massive  upgrades  of  both  hardware  and  software.  An  attractive 
(and  relatively  inexpensive)  alternative  would  be  to  provide 
at  least  certain  users/operators  with  digitizing  tables  or 
tablets  and  maps  of  appropriate  scales  sized  to  fit  onto  those 
tables.  The  user/operator  would  then  locate  the  appropriate 
map,  register  the  map  to  the  table,  and  stream-  or  point-digitize 
the  route.  The  system  would  then  calculate  the  length  of  the 
route . 


5.2  Query  Structure 

,  Transaction  Feature..  Deletion  of  information  from  IISS,  order-of -battle 
records . 

* 

Description.  IISS  contains  many  multi-valued  fields  in  its  order-of- 
battle  records.  These  are  fields  which  can  contain  more  them  one  value 
for  a  particular  data  element.  For  example,  the  list  of  alternate  names 
(nicknames)  for  an  enemy  unit  may  include  "Big  Red  Two,"  "Mackvich's 
Maulers,"  and  "The  Sweet  Second."  If  the  IISS  user/operator  wishes  to 
delete  one  of  these  names  from  the  data  base,  the  name  to  be  deleted 
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must  be  specified  explicitly.  That  is,  if  the  user/operator  wishes 
to  delete  "The  Sweet  Second"  from  the  list  of  alternate  names  for  that 
unit,  the  following  command  string  would  have  to  be  entered: 

FOR  IUNITS  "M0ARMDIV2"  DELETE  ALTNM  "THE  SWEET  SECOND" 

After  this  deletion,  the  contents  of  the  ALTNM  field  for  the  unit 
M0ARMD1V2  will  be  "Big  Red  Two"  and  "Mackvich's  Maulers."  If  the  user/ 
operator  fails  to  specify  the  item  to  be  drleted  explicitly,  all  of  the 
entries  in  the  specified  multi-valued  field  will  be  deleted.  In  other 
words,  if  the  user/operator  enters  the  command  string: 

FOR  IUNITS  "M0ARMDIV2"  DELETE  ALTNM" 

the  ALTNM  field  for  unit  M0ARMDIV2  will  be  blank.  If  the  user/operator 
did  not  mean  to  delete  all  of  the  alternate  names,  the  ones  which  were 
supposed  to  remain  will  have  to  be  added  to  the  data  base. 

Behavioral  implications.  The  user/operator  must  remember  that  explicit 
value  specification  is  required  for  deletion  of  single  items  from  multi¬ 
valued  fields.  In  addition  to  imposing  a  slight  memory  burden,  tnis 
technique  is  somewhat  inconsistent  with  the  method  for  deleting  items  from 
single-valued  fields.  Here,  the  user  does  not  have  to  explicitly  name  the 
value  to  be  deleted  because  there  is  only  one  item  in  the  field.  The  user 
may  become  habituated  to  using  the  delete  verb  without  an  object.  The 
same  process  may,  of  course,  result  in  the  inadvertant  deletion  of  items 
for  multi-valued  fields. 

Transactional  Implications.  The  chance  of  accidentally  deleting  items 
from  multivalued  fields  is  increased.  If  the  error  is  undetected,  the 
integrity  of  the  data  is  compromised.  If  the  error  is  detected,  the  user 
must  reenter  one  or  more  items. 

Consequences .  Other  IISS  analysts  may  be  unaware  that  the  data’  base  is 
not  accurate.  They  may  attempt  to  use  a  multi-valued  field  as  a  global 
search  parameter,  raising  the  possibility  that  a  record  that  should  have 
been  a  "hit"  will  not  be  included  in  the  list  of  retrieved  records. 
Analysts  with  update  privileges  may  spend  time  reentering  information  to 
correct  inadvertant  deletion  errors.  Commanders  may  receive  incomplete 
and/or  inaccurate  intelligence  summaries. 

Recommended  Resolution.  Provide  a  verification  step  for  deletion  of 
items  from  multi-valued  fields.  In  the  example  above,  for  instance, 
entry  of  the  delete  command: 

FOR  IUNITS  "M0ARMDIV2 "  DELETE  ALTNM 

would  result  in  the  following  verification  message: 

YOUR  COMMAND  WILL  DELETE  THE  FOLLOWING  ITEMS  FROM  FIELD  ALTNM: 

1.  BIG  RED  TWO 

2.  MACKVICH'S  MAULERS 

3.  THE  SWEET  SECOND 
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ENTER  THE  NUMBER (S)  OP  THE  ITEM(S)  TO  BE  DELETED,  OR  PRESS  ENTER 
ONLY  TO  DELETE  ALL  OF  THE  ITEMS  — 


Transaction  Feature.  Use  of  orientation  information  in  TACOB  data  base 
structure. 

Description.  The  TACOB  data  base  of  IISS  does  not  currently  contain  any 
information  on  the  orientation  of  enemy  units  (i.e.,  which  direction  they 
are  facing  in  field  locations) .  This  information  is  of  interest  to  GOB 
analysts  who  use  IISS.  Currently,  any  information  on  the  orientation  of 
enemy  units  must  be  stored  in  the  "remarks"  section  of  the  enemy  unit 
records.  Data  in  this  section  are  not  available  as  quantitative  records 
for  treatment  by  the  GIM-II  processing  system.  The  user  cannot,  for 
instance,  calculate  the  average  orientation  of  a  group  of  enemy  units, 
nor  can  the  history  of  unit  orientation  be  conveniently  tracked. 

Behavioral  Implications .  The  user/operator  cannot  conveniently  use 
information  which  is  of  considerable  importance  to  him/her.  Storing 
orientation  data  in  the  "remarks"  section  of  the  record  forces  the  user/ 
operator  to  perform  time-consuming  and  difficult  manual  analyses.  This 
leads  to  user/operator  frustration  and  questioning  of  the  value  of  the 
automated  system. 

Transactional  Implications.  If  it  is  done  at  all,  treatment  of  orienta¬ 
tion  data  is  extremely  inconvenient  for  the  user/operator.  Analyses  of 
orientation  patterns  and  history  require  much  more  time  than  would  be 
required  with  automated  orientation  analysis  routines. 

Consequences .  Battlefield  commanders  may  be  unable  to  receive  important 
analyses  of  enemy  unit  orientation.  If  such  analyses  are  performed, 
they  may  arrive  too  late  for  the  commander  to  use  in  battle  planning. 

Recommended  Resolution.  Include  orientation  as  a  data  element  ’in  appro¬ 
priate  IISS  GOB  data  bases.  Also  develop  routines  for  exploiting 
orientation  data  in  ways  that  are  of  maximum  benefit  to  GOB  analysts. 


Transaction  Feature.  Route  search  function. 

Description.  Tn  some  intelligence  applications,  it  is  useful  to  perform 
a  geographic  search  in  a  band  along  a  defined  line.  For  exmaple,  the  GOB 
analyst  may  wish  to  retrieve  all  records  on  enemy  units  within  n  miles 
of  a  particular  roadway  or  waterway.  Another  possibility  is  searching 
along  the  border  of  a  particular  country  or  other  geopolitical  entity. 
IISS  provides  this  capability  by  allowing  users/operators  to  perform 
polygon  searches.  Specifying  a  polygon  search,  however,  requires  entry 
of  twice  as  many  points  (geocoordinates  or  place  names)  as  does  the  route 
search  function. 

Behavioral  Implications .  The  user/operator  is  required  to  enter  redun¬ 
dant  information  for  certain  types  of  geographic  searches. 
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Transactional  Implications .  The  user/operator  will  require  mors  time 
than  is  required  to  specify  certain  types  of  geographic  searches.  Sin' 
the  amount  of  information  to  be  entered  is  doubled,  the  probability  of 
random  error  is  also  doubled. 

Consequences .  Delivery  of  information  to  battlefield  commanders  may 
be  delayed.  The  probability  that  the  area  will  have  been  erroneously 
defined  is  doubled;  there  is,  therefore,  greater  likelihood  that  the 
commander  will  receive  incorrect  intelligence  information. 

Recommended  Resol u tion .  Add  a  route  search  capability  to  IISS. 


6.  GLOSSARIES 


6.1  Standard  Terms 

,  Transaction  Feature.  Automated  creation  of  data  values. 

Description .  IIS3  automatically  calculates  and/or  inserts  data  values 
where  they  are  available  from  stored  system  information  or  can  be  cal¬ 
culated  from  it.  Automatically  created  data  entries  include: 

1.  Geocoordinates . 

2.  Date  of  update. 

3.  Position  track  information. 

Behavioral  Implications.  USS  users/operators  need  perform  no  activity 
to  ensure  entry  of  this  kind  of  data.  Transaction  time  and  error  pro¬ 
bability  are  thus  minimized. 

Transactional  Implications.  Probability  of  error  in  data  and  command 
entry  is  reduced  to  virtually  zero;  no  user/operator  time  is  required. 

Consequences .  Data  base  integrity  is  guaranteed.  Time  to  complete  data 
entry  is  reduced,  assuring  battlefield  commanders  of  timely  receipt  of 
required  intelligence  information. 

Recommended  Resolution.  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 

,  Transaction  Feature.  Terminology  employed  in  IISS  command  languages  and 
menus . 

Description.  IISS  uses  at  least  three  separate  command  methods:  the 
TELETYPE  mode,  the  MMI  forms,  and  the  GIM-II  language.  In  general,  the 
terminology  used  is  consistent.  There  are,  however,  some  examples  of 
completely  different  terminology  used  to  designate  the  same  function. 

For  example,  the  MASTER  MENU  (Figure  7)  uses  the  term  MARK  to  refer  to 
the  capability  to  change  the  classification  and  caveat  headers.  In  the 
TELETYPE  mode,  the  command  HEADER  is  used. 

Behavioral  Implications.  The  user  is  forced  to  remember  two  different 
command  terms  for  the  same  function.  This  is  an  unnecessary  memory  bur¬ 
den,  and  may  lead  to  confusion. 

Transactional  implications.  A  us®r/operator  accustomed  to  one  mode  of 
command  may  look  for  or  attempt  to  use  the  familiar  command  in  a  dif¬ 
ferent  mode.  In  one  case,  this  command  term  will  not  exist.  In  the 
other,  use  of  the  invalid  command  will  result  in  an  error  message.  The 
correct  command  will  then  have  to  be  entered  to  perform  the  desired  oper¬ 
ation. 

Consequences .  Delivery  of  important  intelligence  information  to  the 
battlefield  commander  may  be  delayed. 
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Recommended  Resolution ‘  Establish  and  enforce  consistency  ir  IISS  com¬ 
mand  terminology. 


6.2  Abbreviations  and  Coding 


Transaction  Feature.  Consistency  in  command  abbreviation  and  coding. 

Description.  Command  and  data  entry  terms  should  be  consistent  to 
minimize  confusion.  In  general/  IISS  codes  and  abbreviations  are  quite 
good  in  this  regard.  There  are,  however,  some  exceptions.  In  the  TACCB 
record  element  abbreviations,  for  example,  the  term  "message"  is  abbre¬ 
viated  in  the  following  ways: 

ABBREVIATION  .  MEANING 


MORIG 

Message 

Origination  or  Originator 

ACMSG 

Message 

MIDEN 

Message 

Identifier 

MGTXT 

Message 

Text 

Behavioral  Implications.  The  use  of  several  different  methods  for  creat¬ 
ing  mnemonic  abbreviations  will  result  in  dissonant  habit  formation  pat¬ 
terns.  This  results  in  an  affective  memory  loading  which  is  much  higher 
than  that  which  would  be  required  to  learn  a  consistently  designed  set  of 
codes. 

Transactional  Implications.  Inconsistent  codes  will  be  more  difficult 
for  IISS  users/operators  to  recall,  requiring  that  users  access  HELP 
files  or  refer  to  IISS  documentation.  Difficulty  in  recalling  codes  is 
also  likely  to  increase  input  error  rate.  The  normal  difficulty  in 
recalling  codes  from  a  large  code  set  is  exacerbated  by  the  inconsistency 
in  code  sets. 

Consequences .  The  increased  error  rate  caused  by  inconsistent  codes 
will  result  in  delayed  delivery  of  intelligence  information  to  battle¬ 
field  commanders. 

Recommended  Resolution.  Establisu  and  maintain  consistency  in  IISS  codes 
and  abbreviations.  . 
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7.  ERROR  HANDLING 


7.1  Error  Prevention 


Transaction  Feature.  Legality  of  various  date  formats  for  entry  of  order- 
of-bact.ie  date  record  elements. 

Description.  IISS  allows  its  users/operators  to  use  any  of  seven  formats 
for  entry  of  dates.  The  first  of  January*  1981  can  be  entered  in  any  of 
the  following  forms: 

1.  January  1,  1981 

2.  1  Jan  1981 

3.  1  Jan  81 

4.  1-1-81 

.5.  1/1/81 

8.  1  January,  1981 

7.  1- Jan-81 

Behavioral  implications .  The  IISS  users/operators  do  not  have  to  remember 
one  particular  date  format.  Date  format  habits  formed  in  other  contexts 
(civilian  experience,  other  U.S.  Army  systems,  U.S.  Army  forms,  etc.) 
are  likely  to  be  permissible  in  IISS  data  entry  tasks. 

Transactional  Implications.  The  likelihood  of  error  in  date  entry  is 
considerably  reduced.  Less  time  will  be  expended  in  correcting  date 
entry  errors. 

Consequences .  Battlefield  commanders  will  receive  accurate  date  infor¬ 
mation  in  IISS  intelligence  products. 

Recommended  Resolution.  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Indication  of  data  element  maximum  size  in  IISS 
data  and  command  entry  forms. 

Description.  The  maximum  length  of  entries  in  command  and  data  entry 
displays  is  indicated  by  blanks  or  "underlines"  on  the  displays. 

Behavioral  Implications ..  Maximum  field  length  information  serves  as  a 
memory  aid  for  the  users/operators,  thus  reducing  the  total  memory  bud- 
den.  ' 


Transactional  Implications.  Errors  in  command  and  data  entry  are  reduced. 

Consequences .  Intelligence  information  is  received  more  quickly  by 
battlefield  commanders.--- 

Recommended  Resolution ■  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 
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7,2  Error  Detection 


Transaction  Feature.  Evaluation  of  string  length. 

Description.  IISS  evaluates  the  length  of  input  strings  with  respect  to 
both  minimum  and  maximum  size. 

Behavioral  implications.  IISS  users/operators  need  not  review  data 
entered  to  determine  whether  they  meet  maximum  and  minimum  length  require¬ 
ments. 

Transactional  Implications .  The  time  required  to  review  data  entries  is 
reduced.  The  integrity  of  the  order-of-battle  data  bases  is  maintained. 

Consequences .  Battlefield  commanders  will  receive  more  accurate  intelli¬ 
gence  information. 

Recommended  Resolution.  None  required,  except  as  noted  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Data  entry  string  content  evaluation. 

Description .  Where  the  number  of  possible  entries  for  a  given  order-of- 
battle  record  is  small,  the  GIM-II  system  determines  whether  the  input 
value  is  legal.  If  not  legal,  an  error  message  is  displayed. 

Behavioral  implications.  IISS  users/operators  need  not  be  concerned 
about  data  entry  errors  for  certain  classes  of  input  information.  The 
IISS  will  automatically  evaluate  the  validity  of  input. 

Transactional  Implications.  Data  base  integrity  is  maintained.  IISS 
users/operators  do  not  have  to  spend  time  reviewing  some  order-pf-battle 
data  elements  before  submitting  input  to  the  AN/GYQ-21(V)  for  data  base 
update. 

Consequences .  Battlefield  commanders  will  receive  more  accurate  intelli¬ 
gence  information. 

Recommended  Resolution.  None  required,  except  as  indicated  in  other  Trans¬ 
action  Feature  Analyses. 


Transaction  Feature.  Error  detection  in  command  entry.' 

* 

Descri ption .  Error  correction’  will  be  simplified  if  errors  are  detected 
as  soon  as  possible  after  they  are  made.  In  the  GIM-II  language  mode  of 
IISS,  for  example,  the  user/operator  may  enter  relatively  long  command 
strings.  Many  of  the  elements  of  the  command  string  are  standard  GIM-II 
language  commands,  which  are  not  enclosed  in  literals  (quotes)  used  to 
designate  data  (as  opposed  to  command  terms) .  IISS  does  not  evaluate  the 
command  until  the  entire  string  is  entered. 
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Behavioral  implications.  The  user  must  enter  more  keystrokes  {.and  thus 
take  more  time)  to  correct  errors  in  command  strings  which  are  not  eval¬ 
uated  until  the  entire  string  is  entered. 

Transactional  Implications.  More  time  will  be  required  to  correct  typo¬ 
graphical  errors  than  would  be  the  case  if  commands  were  evaluated  for 
legality  as  they  were  entered. 

Consequences.  Delivery  of  intelligence  information  to  battlefield  com¬ 
manders  will  be  delayed.  Users  will  be  frustrated  by  the  inconvenience 
of  the  error  detection  process. 

.Recommenced  P.esoJ [ u tion .  Evaluate  GIM-II  language  command  strings  as 
soon  as  they  are  entered.  The  processing  capability  of  the  AN/GYQ-21 (V) 
cannot  be  used  for  this  purpose,  since  there  is  no  communication  between 
the  SY  165?  and  the  IISS  processors  until  the  entire  command  line  has  been 
generated.  The  processing  capabilities  of  the  SU  1652  might,  however,  be 
used  for  this  purpose;'  Legal  values  for  GIM-II  commands  could  be  stored 
in  SU  1652  memory  or  in  local  peripheral  storage. 


7.3  Error  Feedback 


.  Transaction  Feature.  IISS  error  messages. 

Description.  The  information  content  of  IISS  error  messages  is  often 
quite  low.  Table  A-2  provides  some  examples  of  IISS  error  messages,  as 
well  as  the  actual  conditions  which  caused  the  error. 

Behavioral  Implications.  The  IISS  error  messages  are  too  vague  to  permit 
users/operators  to  qi  sly  grasp  the  precise  error  condition  involved. 
Furthermore,  the  stilted,  formal  grammar  and  syntax  of  the  error  messages 
may  make  it  difficult  for  the  users/operators  to  interpret  the  .reference 
of  the  error  messages. 

Transactional  Implications.  Difficulty  in  interpreting  the  error  messages 
will  increase  the  time  required  for  error  detection  and  subsequent  error 
correction. 

Consequences .  Delivery  of  intelligence  information  to  the  battlefield 
commander  may  be  delay."’. 

Recommended  Resolution .  Modify  the  t*  ror  messages  along  the  lines  sug¬ 
gested  in  the  "Recommended  Error  Message"  column  of  Table  A-2. 

7.4  Error  Correction/Recovery 


Transaction  Feature .  Error  correction  for  multi-line  commands. 

Description.  The  SU  1652  has  pure  cursor  move  commands  which  allow  the 
user/operator  to  copy  information  already  on  the  screen.  While  copying. 
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Table  A- 2 


IISS  Error  Conditions,  Error  Messages,  and 
Recommended  Error  Messages 


ERROR  CONDITION 

IISS  ERROR  MESSAGE 

RECOMMENDED  ERROR  MESSAGE 

Th*  usar/ooarator  Ml  triad  to  add  informa¬ 
tion  to  tlM  CU.NITS  fill.  This  1i  lllegsl; 

(  information  must  bt  add id  to  either  tht 
|  (UNITS  or  UUNITS  segment  of  th*  CUN  ITS  fill. 

7(93  This  Oats  list  hot  access! - 
bla  to  updata. 

You  cannot  add  data  to  tht  EUNITS  flit.  Please  specify 
tlthtr  tht  IUNIT  of  UUNITS  flit. 

•  The  u$*r/Cp«r4cor  h*$  tried  to  us*  th*  3lM.II 

{  f«ry  ACO  fj  jiter  *t1$ting  current  name 

'f  jo  v.nit  /<T*.  ’■*  *IM-;j  vero 

1  Change  «ust  :*  -sed  *M*  purpose. 

1021  Tn  Item  ID  "HAGAV66666" 

the  attribute  whose  AMC  1i 
4i$s  single  value  reject 

I  end  a  i  ri*<jy  has  «  valu*  on 

1  the  flit. 

You  cannot  us*  the  ADO  verb  to  change  the  current  reme 
of  the  Identified  unit  HAGAV65666.-  If  you  went  to  j 

chenge  it,  us*  the  CnAUGE  verb. 

'  5 

i  >*  usar/ooarator  n*s  triad  to  assign  a  COM- 

1  SAT  READINESS  RATING  CATE  'RRDAT)  Milan  thara 

■  It  no  COMSAT  READINESS  RATING  itorld  in  tht 

1  file  or  anterao  in  tha  iua  cgoaaand  Ifna  as 

■  tha  RRDAT  Chang*. 

7214  This  statamant  has  failad 
its  adit  spacifleition. 

You  cannot  add  RRDAT  unless  (!)  there  Is  liraady  a 

CH0RR  in  tha  file  or  (2)  you  also  add  a  CUR*  In  tha 
sum  lint  as  tha  RRDAT  idditlon. 

Thara  is  currently  no  CM0RR  for  UUNIT  »UN*99999." 

*w«  uier/ortretcr  Ms  tried  to  enter  a  new 
f  locution  without  also  entering  a  CHANGED 

|  UCAUCN  CATE  (CLCAT). 

7214  This  statamant  hat  failad 
its  adit  spacifleition 

Whan  you  add  a  new  unit  location  (UTttLO  or  GEOLO)  you  g 
must  also  add  a  changt  location  date  (CL0AT) .  i 

j 

Tha  cser/o cantor  hat  attainted  td  add  tha 
NUMBER  OF  CATS  OF  TRAINING  (NOPAY)  tor  a 
unit  without  also  entering  a  TRAINING  TYRE 
(TRTyP). 

7608  Tha  02  attributa  "NOCAY  is 
not  dlractly  pracadad  by 

its  oi. 

You  must  enter  the  training  type  (TRTYP)  before  you 
enter  the  number  of  deyt  of  training  ( NODAr )  for  thet 
training  type. 

Tha  gser/ocaritor  has  attemotad  to  add  a  run¬ 
way  specification  to  tha  RUNWAY  FILE  (RWY) 
whan  tha  runway  10  dots  not  alraady  exist 

In  tha  AIRFIELD  FILE  (ARFLO) . 

1040  Tha  sacondary  TD  *70000* 
4321-20210*  is  a  brtdga  and 
verify,  but  is  not  on  tht 
flit. 

Than  is  no  runway  ID  *7p0f*4321-p0tlp‘  in  the  airfield  I 
Ml*  (ARFLO).  ptaasa  check  this  runway  10,  dr  add  it 
to  tht  appropriate  airfield  flit  entry. 

Tha  user/operator  has  fallad  to  uta  a  lagal 
data  format  for  tha  Raquirad  Information 

Data  (REOAT). 

330  Vtlut  found  for  input  dttt 
contortion  not  csnvtrtiOlt. 

You  havt  used  an  Illegal  format  for  th*  raquirad  Infor¬ 
mation  data  (REDAT).  Uta  on*  of  tht  following  date 
formats  1 

1.  1- JAN-01 

2. 

Yh«  utar/oparator  hat  flalad  to  uta  a  lagal 
format  for  tha  Activity  Addrattea  (PRAOR). 

7007  *AA*EliTRY2*R*  fills  to  PISS 
Its  pstttrn  audit. 

7016  Statamant  tarmtnatad  dua  to 
S/EDIT  ERROR 

You  hav*  used  an  Illegal  format  for  th*  activity  addras- 
sa*  (PRAOR).  The  lagal  format  Is: 

1.  Node. . .2  characters 

2.  Analysts  function  nan*. ..10  characters 
(maximum) 

3.  Responsibility  coda... 1  character 

4.  Processing  fl  g...l  charactar 

With  aach  item  sap* rated  from  th*  noxt  by  an  asterisk 
(*).  Exsmpla: 

*AA*ENT*Y1*0*P* 

Tha  usar/oparator  has  ftalad  to  add  a  llna 
numoar  to  tha  Massaga  (ACMS6)  flald  In  tht 
ActtYity  Fill  (ACTF). 

7009  UFNEEOCOVERFIRE  fails  to 
pats  Hs  maximum  sita 
restrictions. 

7010  WENEE0C0VERFIRE  falls  to 
pass  its  mimimum  slit 
rtstrletions. 

7016  Statamant  tamtnattd  due 
to  S/EOIT  ERROR. 

You  have  used  an  illegal  format  for  tha  massaga  field 
(ACMSG).  You  must  inter  a  thraa  digit  massaga  llna 
number,  followed  by  up  to  74  characters  of  message 
ttkt.  Example: 

*0P1*TMIS  IS  LINE  1* 

■002*THIS  IS  LINE  2* 

Stperett  the  lint  number  from  the  message  text  with  an 
aattrisk  (*). 

Tha  usar/oparator  has  aotarsd  s  two-char- 
actar  coda  for  tha  sacurity  classification 
(SECLS)  in  tha  Request  for  Intalliganca 
Information  Fill  (RIIF).  Only  one- 
eharactar  codas  ara  valid. 

7009  TT  fills  to  pill  Its  max¬ 
imum  slit  restrictions. 

7016  Statement  tansinitad  dua 
to  S/EDIT  ERROR. 

You  may  antar  only  a  ona-charactar  code  for  th*  sacurity 
classification.  The  legel  values  are  *T,"  "s,*  *C,' 

*R,"  and  "U.“  Your  entry  of  IT  Is  Illegal. 
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the  user/operator  may  also  make  editing  changes  to  correct  errors  made 
in  original  entry  of  the  command  string.  When  in  GIM-II  Language  mode, 
the  user/operator  may  at  times  enter  several  lines  of  commands  before 
pressing  the  SEND  key  to  pass  the  commands  to  the  AN/GYQ-21 (V) .  If  there 
is  an  error  in  the  command,  the  user/operator  may  use  the  cursor  to 
recopy  the  command  up  to  the  point  where  the  error  occurred,  correct 
the  error,  and  then  copy  the  remainder  of  the  command.  It  can  then  be 
transmitted  to  the  central  computer  for  evaluation.  As  IISS  is  currently 
structured,  however,  the  user/operator  must  make  a  change  in  each  line  of 
a  multi-line  command,  even  when  there  is  no  error  in  that  line. 

Behavioral  Implications.  The  user/operator  is  forced  to  make  irrele¬ 
vant  changes  to  command  lines  to  ensure  eventual  acceptance  of  the 
commands  by  the  system  processor.  This  process  wastes  time.  In  addi¬ 
tion,  the  requirement  to  make  at  least  one  change  in  all  lines  of  a 
multiple-line  command  containing  an  error  is  easily  forgotten,  since 
the  procedure  is  an  essentially  illogica-i.  one. 

Transactional  Implications.  Correction  of  errors  will  take  more  time 
than  would  be  required  for  a  better  designed  error  correction  procedure. 
The  probability  of  multiple  errors  is  increased,  since  the  user/operator 
may  forget  the  seemingly  unnecessary  requirement  to  make  changes  in  what 
appears  to  be  valid  command  entries.  Inexperienced  users/operators  may 
not  be  able  to  determine  why  the  system  refuses  to  accept  seemingly  valid 
commands.  ... 

Consequences .  Users/operators  may  become  extremely  frustrated  with  the 
system.  Because  of  increased  time  to  correct  errors  and  the  increased 
likelihood  of  multiple  (sequential)  errors,  intelligence  information  may 
be  delayed  in  reaching  battlefield  commanders. 

Recommended  Resolution.  Eliminate  the  requirement  for  making  changes  to 
all  lines  of  multiple-line  commands  in  which  there  is  an  error  in  one  of 
the  lines. 
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APPENDIX  B 


SU  1652  FIXED  FUNCTION  KEYS  USED  IN  IISS 


UPPER  FIXED  FUNCTION  KEYS 


INSRT 

L. . . 


r  next' 
PAGE 


PREV 

PAGE 

i  * 


F"  1 

LOAD 

>1.  ,i  — < 


KEY  LABEL 


KEY  FUNCTION 


Permits  Insertion  of 
characters  in  existing 
variable  fields. 


In  normal  operation,  the  terminal  replaces 
characters  overlaid  by  the  cursor.  When 
the  user  presses  the  INSRT  key  and  then 
enters  a  character,  the  existing  character 
overlaid  by  the  cursor  i3  shifted  one  space 
and  the  input  character  is  inserted  into 
the  resulting  empty  space. 


Page  forward  to  the  next 
page  of  data. 


Permits  the  user  to  page  forward  to  select 
the  next  page  of  data  in  the  SA  where  cursor 
is  located.  There  must  be  more  than  one 
page  of  data  in  the  SA  for  this  FFK  to  be 
effective. 


Page  backward' to  select  a  Allows  the  user  to  page  backwards  to  select 
previous  page  of  data.  a  previous  page  of  data  in  the  same  SA  where 

the  cursor  is  located.  There  must  be  a  pre¬ 
vious  page  of  data  to  the  current  page  being 
displayed  for  this  FFK  to  be  effective. 


Allows  the  internal 
terminal  program  to 
be  loaded. 


Used  in  conjunction  with  the  INIT  (left  FFK) . 
Immediately  after  depressing  the  INIT  FFK, 
depressing  the  LOAD  FFK  causes  the  internal 
terminal  program  to  be  loaded.  The  LOAD 
key  is  "on"  when  beginning  terminal  operation 


Initialize  the  terminal 


IN  I T 

h— n  — 


Clear  the  input  field. 


PREV 

FLD 

Li  .■■■■■ 


Move  the  cursor  to  the 
first  character  in  the 
previous  field. 


Advance  the  cursor  to  the 
first  character  in  the 
next  input  field. 


Read  the  indicated  data¬ 


set  a  position  marker 


Initialize#  the  user  terminal  before  the 
l<OAD,  upper  fixed  function  key  is  depressed. 
The  I NIT  key  is  QN  when  beginning  terminal 
operations. 


Clears  (makes  blank)  the  input  field 
indicated  by  the  cursor. 


Moves  the  cursor  to  the  first  character 
in  the  previous  input  field  in  the  current 
SA  (screen  area) . 


Moves  the  cursor  to  the  first  character 
in  the  next  input  field  in  the  current 
SA. 


Signals  the  system  computer  to  read  the 
data  in  the  SA  indicated  by  the  cursor 
and  causes  the  active  SA  where  the  cursor 
is  positioned  to  become  inactive. 


Place  a  mark  at  the  cursor  position.  Two 
of  these  symbols  identify  the  start  and 
end  position  of  data  to  be  copied,  moved 
or  deleted. 


LEFT  FIXED  FUNCTION  KEYS 


KEY  LABEL 

KEY  FUNCTION 

ERASE 

MARK 

Restore  one  or  two  marked 
characters. 

At  the  end  of  editing ,  restores  the  one  or 
two  marked  characters  zo  their  previous 
values  by  removing  the  mark. 

'  i  ' 

Y 

Move  the  cursor  down. 

i 

Lowers  the  cursor  one  line. 
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RIGHT  FIXED  FUNCTION  KEYS 


KEY  LABEL 

KEY  FUNCTION 

Duplicate  data. 

Duplicates  the  data  between  two  marks  pre¬ 
viously  placed.  The  cursor  must  be  moved 
to  a  variable  field  to  receive  the  data 
to  be  copied. 

EM 

Delete  the  character  one 
space  to  the  left. 

Erases  the  character  one  space  to  the  left 
of  the  cursor  and  backspaces  the  cursor 
one  space. 

Shift  a  line  down. 

Shifts  a  current  line  marked  by  the  cursor 
down  one  line.  Erases  the  top  line  and 
repositions  the  cursor  at  the  beginning 
of  the  input  field. 

Delete  the  character  marked 
by  the  cursor. 

Deletes  the  character  overlaid  by  the  cursor 
and  moves  the  remaining  characters  in  the 
line  one  space  left  to  fill  in  the  gap. 

\ 

Delete  the  word  marked  by 
the  cursor. 

Removes  all  of  the  continuous  characters 
forming  the  word  beginning  with  the  cursor 
position  and  ending  ?fter  the  first  blank 
character.  //No  indication  that  it  fills  in./ 

LINE  | 

lej 

Delete  the  line  marked 
by  the  cursor. 

Removes  the  entire  line  indicated  by  the 
cursor  and  moves  subsequent  text  fields 
ui  one  line.  Fills  in  the  last  line  with 
blanks . 
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RIGHT  FIXED  FUNCTION  KEYS 
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APPENDIX  C 

SJ  1652  VARIABLE  FUNCTION  KEYS  USED  IN  IISS 


Bring  up  first  display  page. 


Returns  to  the  first  page  any  time  the 
user/operator  is  on  other  than  the  first 
page  of  a  multi-page  display. 


Advance  the  cursor  to  the 
next  screen  area. 


Advances  the  cursor  to  the  first  variable 
fieJ.d  in  the  next  screen  area. 


Erase  the  indicated  screen  Erase  the  entire  screen  area  in  which 
area*  the  cursor  is  currently  positioned. 


Restore  key  functions. 


Restores  the  alphanumeric  keyboard,  the 
Fixed  Function  Keys  and  the  Variable 
Function  Keys  to  an  oparating  condition. 


Prepare  for 


command  line. 


Erases  screen  area  6  and  moves  the  cursor 
to  the  home  position  in  screen  area  6  in 
preparation  for  an  executive  level  GIM-II 
command  from  the  user. 


Reserved  (unused)  key. 


This  key  is  not  used  in  the  first  milestone 
system,  but  is  reserved  for  future  use. 


RIGHT  VARIABLE  FUNCTION  KEYS 


print' 

OISP 


r 

PRINT 

PAGE 

- 


LOGON 


KEY  LABEL 


Print  the  display. 


Print  the  page. 


Log  on  to  the  terrdnal. 


Log  off  of  the  terminal. 


Stop  processing  temporarily. 


KEY  FUNCTION 


Prints  all  pages  of  a  display  in  the  screen 
area  indicated  by  the  cursor  position. 


Prints  the  single ,  visible  page  of  n 
screen  area  as  indicated  by  the  cursor 
position. 


Displays  the  LOGON  form  in  screen  area  5. 


Disconnects  the  user  from  the  system, 
blanks  five  of  the  screen  areas,  prompts 
for  a  LOGON  ir  screen  area  six  and  enables 
the  IOGCN  VFK. 


Temporarily  suspend*,  the  output  stream 
to  the  terminal  from  the  statement  in 
progress. 


m-j 


Cancels  the  statemant  in  progress  if  possible 


Resumes  the  output  stream  to  the  terminal 
from  the  statement  halted  by  the  STOP 
right  VFK. 


Requests  and  displays  the  current  status 
or  tho  statement  in  progress. 


i 

i 

i 

1 

FASTER 

1ENU 

Display  the  master  menu. 

Displays  the  MASTER  MENU  in  screen  area  two. 

! 

i 

HALT 

Deactivate  the  terminal. 

Deactivates  the  user  terminal. 

V 

:onfro 

Remove  the  terminal  mode. 

Removes  the  terminal  mode  which  was  initiatec 
by  the  user  of  command  DISPLAY  ALL#. 

pri 

PAGE 

LIMIT 

|  Proceed  past  the  maximum 
j  page  limit. 

This  key  can  be  used  when  viewing  the  50th 
output  page.  The  user  pushes  this  key 
to  continue  viewing  the  next  set  of  pages, 
but  it  is  not  possible  to  return  to  the 
previous  set  of  50  pages. 

Display  current  status. 


*1  Resume  processing. 


GO 

k.  <d 
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RIGHT  VARIABLE  FUNC"  -l  KEYS 


KEY  LABEL  I  KEY  FUNCTION 


interrupt  time  sharing  When  in  TSS  this  key  interrupts  a  .  rticular 

function.  function  being  performed  in  -  .haring 

and  returns  the  user  to  ‘  next  lev^i 
primitive  used  previc:  ^.y. 


Disconnec"  •  time  shatvng.  When  in  TSS  thi^  key  will  cause  m  immediate 

disconnect  from  the  host  Honeywell  6000 
computer  and  return  the  user  to  the  master 
menu. 


LEFT  VARIABLE  FUNCTION  KEYS 


KEY  LABEL 


KEY  FUNCTION 


Select  user  input  form. 


Displays  the  appropriate  input  form  to 
receive  user  inputs  for  data  retrieval 
with  a  structured  output  format. 


Display  GIM  input  form. 


Displays  an  input  form  for  the  user  to 
enter  a  selection  clause  when  retrieving  dat 
in  the  structured  format,  and  displays 
structured  output.  For  GIM  mode  only. 


Update  a  GIM  field  or  record. 


Can  add  data  to  an  existing  GIM-Ix  field 
or  record,  or  add  a  complete  record.  Can 
change  or  replace  selected  data  in  a  GIM-II 
field  or  record.  Can  delete  an  entire  GIM- I 
record  from  the  data  base. 


Retrieves  the  next  record  in  the  Activity 
File  that  has  been  marked  to  the  attention 
of  a  user  by  the  disseminator  processor. 


A ppi_  .Return  to  the  beginning 

RESTR  °f  the  GIM  menu  option. 


Returns  to  the  beginning  of  the  application 
(menu  option)  that  the  user  has  selected. 


Displays  the  GIM  MENU  and  permits  the  user 
to  light  pen  select  any  menu  option  present. 


LEFT  VARIABLE 


KEY  LABEL 


End  JINTACCS  formatted 
message . 


Return  to  the  INDEX  LIST. 


KEYS 


KEY  FUNCTION 


Stops  construction  of  a  JINTACCS-formatted 
message  when  conducting  the  IN  ANAL  menu 
option . 


When  pressed  while  the  user  is  working  with 
a  full  record  display,  this  key  returns 
the  display  to  the  index  List  so  the  user 
can  select  another  record. 


APPENDIX  D 

DISCUSSION  OF  SOFTWARE  ELEMENTS  IN  IISS 
RELATED  TO  USER/OPERATOR  TRANSACTIONS 
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INTRODUCTION 

The  IISS  FMS  is  a  highly  complex  intelligence  support  At?  system.  As 
such,  many  of  its  software  capabilities  are  appropriately  reserved  for  use 
by  system  operations  and  maintenance  personnel.  The  discussion  here  will 
be  limited  to  software  capabilities  with  which  the  primary  system  users  (i.e. 
USAREUR  GOB  analysts)  interact. 

GENERAL  STRUCTURE  OF  IISS  FUNCTIONAL  CAPABILITIES 

The  general  structure  of  IISS  functional  capabilities  is  depicted  in 
Figure  D-l.  Following  a  successful  logon,  the  user  is  presented  with  the 
IISS  MASTER  MENU  (Figure  D-2) .  Using  this  menu,  all  analyst-relevant  IISS 
capabilities  can  be  selected  by  touching  the  light  pen  to  the  desireu  func¬ 
tion.  The  functions  available  from  the  MASTER  MENU  include  four  which  are 
restricted  (i.e.,  they  may  or  may  not  be  available  to  individual  users, 
depending  on  their  position  and  status).  These  four  restricted  options  are: 

1.  START  DEVICE— used  to  start  (logically  connect)  a  currently 
inactive  IISS  hardware  device. 

2.  STOP  DEVICE — used  to  stop  (logically  disconnect)  an  IISS 
hardware  device  which  is  currently  active. 

3.  SANITIZER— used  to  strip  classified  information  from  re¬ 
ports  and  datasets  which  must  be  transmitted  over  non- 
secure  data  lines  and/or  reviewed  by  personnel  without 
required  security  clearances . 

4.  PLOT — used  to  plot  installation  or  order-of -battle  data 
derived  from  TACOB  data  base. 

There  are  also  ten  options  which  are  available  to  all  IISS  users: 

1.  WHO — used  to  determine  what  IISS  users  are  currently 
logged  into  the  system. 

2.  HELP—prints  a  brief  list  of  options  in  IISS  processing. 

3.  MARK — enables  the  user  to  change  the  security  classifica¬ 
tion  and  caveat  appearing  at  the  top  of  each  CRT  screen. 
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MSTER  MENU 


\ 

CLASSIFICATION  ***CAVEAT*** 

1 

\  MASTER  MENU 

♦START  DEVICE 
♦STOP  DEVICE 
WHO 
HELP 
MARK 

USER  MESSAGE 
♦PLOT 


_ 

♦Restricted  options 


GIM 

TSS 

BDT 

RJE 

IN  ANAL 
♦SANITIZER 
TELETYPE 
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Figure  D-2.  MASTER  MENU  of  the  IISS.  Redrawn  from  IISS  User's  Manual, 


4 .  USER  MESSAGE — allows  IISS  users  to  send  messages  to  other 
users. 

5.  GIM — used  to  query  and  update  data  bases  via  the  Generalized 
Information  Management  (GIM)  menu  and  language  systems. 

6.  TSS— allows  the  XISS  user  to  communicate  directly  with  the 
EUCOM  AIDES  Honeywell  H-6000  host  computer. 

7.  BDT— permits  the  IISS  user  to  define  and  control  bulk 
data  transfer  from  node  to  node. 

8.  RjE — permits  IISS  users  to  execute  remote  job  entry  batch 
jobs  on  the  Honeywell  H-6000  host  computer. 

9.  IN  ANAL— permits  IISS  users  to  create  messages  in  Joint 
Interoperability  Tactical  Command  and  Control  System 
(JINTACCS)  format. 

10.  TELETYPE— permits  IISS  users  to  bypass  informative  form 

displays  and  itneract  directly  with  the  PDP-11/70  system 
monitor/executive  to  perform  IISS  operations. 

When  selecting  any  of  the  options  (other  than  TELETYPE) ,  the  user  is  presented 
with  an  informative  prompt/form  generated  by  the  IISS  Man-Machine  Interface 
(MMI) .  Using  the  light  pen  and  alphanumeric  codes  entered  from  the  keyboard, 
the  user  fills  out  the  form  and/or  light -pens  appropriate  words  to  further 
define  desired  processing. 

If  the  TELETYPE  option  is  selected,  IISS  no  longer  presents  the  user 
with  MMI -generated  informative  prompts,  in  this  mode  of  operation the  user 
keys  in  a  command  to  perform  the  desired  IISS  function.  The  system  then 
responds  with  informative  feedback  on  the  result  of  the  command  entry.  Many 
of  the  functions  described  earlier  in  connection  with  the  MASTER  MENU  are 


also  available  in  TELETYPE  mode: 

1. 

START  DEVICE 

2. 

STOP  DEVICE 

3. 

SANITIZER 

4. 

WHO 

5. 

HELP 

6. 

MARK 

7. 

USER  MESSAGE 
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8.  GIM 


9.  TSS 

10.  BDT 

11.  RJE 

In  addition  to  these  options,  the  TELETYPE  mode  provides  some  capabilities 
which  are  not  accessible  through  the  MASTER  MENU.  These  include: 

1.  APP — simulates  the  interface  of  an  external  application 
program. 

2 .  COPY — copies  input  statements  to  an  output  location  when 
the  terminal  device  number  is  unknown. 

3.  LPWIC — establishes  digital  communication  with  IDHSC-II 
lines . 

4.  SCRATCH— -scratches  an  entry  from  a  designated  user  queue. 

5.  DSPLY — displays  data  routed  to  a  print  queue. 

Most  of  the  options  in  the  MASTER  MENU  are  " single-purpose "  options. 

That  is,  they  lead  invariably  to  stipulation  of  a  single  set  of  processing 
commands  with  no  significant  procedural  "branches.”  To  put  it  another  way, 
selection  of  most  MASTER  MENU  options  does  not  lead  the  user  to  another  menu 
but  rather  to  a  form  to  be  filled  out  to  define  further  processing.  The  GIM 
option  (as  indicated  in  Figure  D-2)  is  an  exception  to  this  general,  rule. 

Upon  exercising  the  GIM  option,  the  user  is  first  requested  to  sign  on  to 
(specify)  a  particular  GIM  data  base.  This  done,  the  system  then  displays 
the  GIM  MENU,  which  provides  the  following  five  options: 

1.  GIM  LANGUAGE,  which  in  a  manner  analagous  to  the  TELETYPE 
option  of  the  MATTER  MENU,  permits  the  user  to  bypass  the 
detailed  command  entry  forms  of  the  MMI  and  interact  directly 
via  the  GIM  query  language  with  the  IISS  system. 

2.  UTM-GEO  CONVERSION j  which  permits  the  user  to  convert  between 
Universal  Transverse  Mercator  (UTM)  and  latitude/longitude 
geocoordinate  systems. 

3.  REPORTW,  which  permits  the  user  to  define  the  format  and 
content  of  brief,  ad  hoc  reports. 

4.  ANALYSIS ,  which  permits  the  user  to  query  the  TACOB  data 
base. 
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5.  INPUT,  which  permits  the  user  to  add  to  and/or  modify  the 
contents  of  the  TACOB  data  base. 

The  functions  of  all  XISS  options,  as  well  as  the  display  screens  and 
internal  switches  associated  with  the  functions,  are  described  in  more  detail 
below. 


MASTER  MENU  OPTIONS 

Options  from  the  MASTER  MENU  are  selected  by  touching  the  SU  1652  light 
pen  to  the  portion  of  the  CRT  screen  containing  the  desired  option,  and  then 
pressing  the  SEND  key.  This  will  result  in  one  of  the  following  types  of 
system  responses: 

1.  A  form  to  be  filled  in  to  determine  subsequent  processing  or 
provide  IISS  inputs. 

2 .  A  prompt  character  or  string  indicating  that  a  command  string 
should  be  entered. 

3.  A  display  of  user  information. 

4 .  Another  menu . 

5.  A  prompt  for  non-su  1652  terminals. 

If  a  user  accidentally  selects  an  undesired  option  (or  if  the  user  lias 
completed  activities  associated  with  a  particular  option) ,  the  user  can 
press  the  MASTER  MENU  VFK  to  return  to  the  MASTER  MENU. 

Discussions  of  individual  MASTER  MENU  options  appear  below. 

Start  a  Hardware  Device  (START  DEVICE  Option) 

Selecting  the  START  DEVICE  option,  i.e.,  logically  connect  a  hardware 
driver,  results  in  the  display  in  Figure  D-3,  which  appears  in  Screen  Area 
(SA)  5.  This  option  is  drdinarily- reserved  for  use  by  the  Data  Base  Manager 
or  other  designated  personnel.  The  START  DEVICE  option  is  used  to  logically 
connect  any  peripheral  device  currently  physically  connected  and  "mapped  into" 
the  IISS  hardware/software  system  (terminals,  tape  drives,  printers,  disk 


D-6 


drives,  etc.) .  This  option  would  ordinarily  not  be  used  by  an  OB  analyst/ 
user  unless  there  were  a  particular  need  for  user  control  over  a  system  device 


Figure  D-3.  Format  of  the  START  DEVICE  Preformatted  Display.  Redrawn  from 
IISS  User's  Manual,  p.  3-6. 

To  start  a  device,  the  user  types  in  specifications  for  output  or  input 
devices.  Interactive  devices  are  specified  only  on  the  OUTPUT  line  of  the 
display.  In  specifying  device  and  device  connection  parameters,  the  user 
may  use  one  or  more  of  the  following  switches: 

1.  /AP — specifies  that  BDT  or  FJE  output  should  be  routed  to 
the  existing  specified  file. 

2.  /UP — indicates  that  the  existing  version  of  the  output 
file  is  to  be  updated. 

3.  /LO:PRINT0 — specifies  a  list  only  (output  only)  device; 
used  to  start  a  device  which  prints  directed  output. 

4.  /SP/LOS :<<name>> — indicates  that  output  is  spooled  to 
directed  output. 

5.  /LP0:/LO:  <<name» — line  printer.  * 

6.  /MT — indicates  that  the  specified  device  is  to  be  assigned 
as  the  master  terminal. 

7.  /SU — indicates  that  ar  existing  version  of  the  output  file 

is  to  be  superseded;  version  number  of  file  must  be  explicit. 


8. 


/SZ:N — specifies  an  override  line  siza  for  input  or  output 
file. 

9.  /DE — indicates  that  the  input  file  is  to  be  deleted  at  close. 

10.  /NL — indicates  that  the  soft  device  is  not  to  be  logged  on; 

specification  must  contain  logon  name  and  password. 

When  the  form  is  completed,  the  user  presses  the  SEND  key  to  enter  the 
information  into  the  system.  The  system  will  then  automatically  return  to 

the  MASTER  MENU. 

Logically  Disconnect  a  Device  from  IISS  (STOP  DEVICE  Option) 

This  option  is  the  counterpart  to  the  START  DEVICE  option;  it  logically 
disconnects  a  physical  device  currently  attached  to  and  "mapped  into"  the 
IISS  system.  Selecting  the  STOP  DEVICE  option  cuases  the  display  in  Figure 
D-4  to  appear  in  SA  5. 


Figure  D-4.  Format  of  the  STOP  DEVICE  preformatted  display.  Redrawn  from 
IISS  User's  Manual,  p.  3 rl . 

The  designated  user  (this  is  a  restricted  option)  types  the  device  number 
(logical  unit  number)  into  the  appropriate  blank  on  the  form.  If  the  user 
does  not  know  the  device  number,  it  may  be  identified  by  exercising  the  WHO 


option  from  the  MASTER  MENU.  Once  a  device  has  teen  STOPPED,  all  system 
users  will  be  prevented  from  using  it  until  a  START  DEVICE  command  has  been 
issued.  There  are  :io  option  switches  associated  with  this  option. 

Sanitize  File  Contents/Output  (SANITIZER  Option) 

This  option  is  used  to  delete  sensitive  material  from  IISS  files  and 
output  so  that  it  may  be  1)  transmitted  via  non-secure  communications  systems 
and/or  2)  reviewed  by  uncleared  personnel.  Since  the  original  data  were 
supplied  from  a  data  base  containing  highly  classified  intelligence  informa¬ 
tion,  however,  they  must  be  reviewed  hy  appropriate  security  personnel  whether 
or  not  they  have  been  processed  by  the  SANITIZER  software.  This  option  is 
not  currently  used  by  IISS  analysts,  and  therefore  will  not  be  further  dis¬ 
cussed  here., 

Plotting  Installation  ard  Order-of- Battle  Data  (PLOT  Gption) 

This  option  was  intended  to  provide  T1SS  users  with  the  capability  to 
extract  geographically-defir.ed  data  from  order-of-battie  files  and  tc  plot 
the  positions  of  the  extracted  items .  It  is  net  currently  provided  as  a  user 
option ;  plots  are  generated  by  the  highly  experienced  and  qualified  system 
c per ator s/do velopers.  Therefore,  the  PLOT  option  will  not  be  further  dis¬ 
cussed  here. 

Tdidtify  II SS  Users  (MO  Option) 

Ana  Analysts  cvm  determine  who  is  currently  lugged  on  to  the  IISS  system  by 
exercising  the  WHO  option.  Tliis  results  in  a  display  formatted  like  <  hat 
shown  in  Fig^crt  D-o. 

Request  -  List  of  User  Options  (HELP  Option) 

looting  the  HELP  option  results  in  display  of  one  descriptions  of 

IISS  functions  available.  The  display  (shown  in  Figure  D-6  appears  in  SA  S.. 

It  should  be  noted  that  this  display  lists  some  options  which  are  not 
selectable  through  the  M.ESTER- MENU  t 


1. 

COPY 

COPY  INPUT 

TO  OUTPUT 

2 . 

DSP  IV 

DISPLAY  VERB  ENTRY  POINT  FROM  MENU 

3. 

HALT 

LOGOFF  AND 

HALT  TERMINAL 
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Figure  d-5,  Format  of  the  User  Status  Report  (WHO)  Preformatted  Display. 
Redrawn  from  ll'SS  User's  Manual,  p.  3-7. 


4.  HEADER  ALTER  SECURITY  HEADER  (note:  this  appears  to  be 

accomplished  by  the  MARK  option  in  the  MASTER  MENU) . 

5.  LOGOFF  LOG  OFF 

0.  MSG  SEND  MESSAGE  TO  USER  LOCAL  OU  REMOTE  (note:  this 

appears  to  be  identical  to  the  MASTER  MENU  USER  MSG 
option) .  ^ 

7.  NOTE  COMMENTS,  NO  OPERATION 

8.  PRINT  PRINT  VERB  ENTRY  POINT  FROM  MENU 

9.  SCRTCH  SCRATCH  VERB  ENTRY  POINT  FROM  MENU 

Also,  there  are  MASTER  MENU  options  which  are  not  included  in  the  HELP  listing 
1  MARK 

2.  USER  MESSAGE 

« 

3.  IN  ANAL 

4 .  PLOT 

5 .  SANITIZER 


6. 


TELETYPE 


CLASSIFICATION 


***CAVEAT*** 


HELP  --  HELP  OPTION  (SHORT/LONG  MISSING  LONG  DEFAULTED) 

OPTION  DESCRIPTION 

BOT  BULK  OATA  TRANSFER 

COPY  COPY  IN°UT  TO  OUTPUT 

DSPLY  DISPLAY  VERB  ENTRY  POINT  FROM  MENU 

GIM  GENERALIZED  INFORMATION  MANAGEMENT  SYSTEM  (LOCAL) 

HALT  LOGOFF  AND  HALT  TERMINAL 

HEADER  ALTER  SECURITY  HEADER 

HELP  USER  OPTION  LIST 

LOGOFF  LOG  OFF 

MSG  SEND  MESSAGE  TO  USER  LOCAL  OR  REMOTE 

NOTE  COMMENTS,  NO  OPERATION 

PRINT  PRINT  VERB  ENTRY  POINT  FROM  MENU 

RJE  REMOTE  JOB  ENTRY 

SCRTCH  SCRATCH  VERB  ENTRY  POINT  FROM  MENU 

START  START  DEVICE 

STOP  STOP  DEVICE 

TSS  TIME  SHARING  ON  THE  H-6000 

WHO  USER  STATUS  REPORT 


Figure  D-6.  Format  of  the  HELP  Pre formatted  Display.  Redrawn  from  IISS  User's 
Manual,  p.  3-8. 

Change  in  Security  Header  Line  (MARK  Option) 

Selecting  this  option  causes  the  classification  marking  form  (Figure  D-7) 
to  appear  in  SA  5. 


Figure  D-7.  Format  of  the  Classification  Marking  (MARK)  Preformatted  Display. 
Redrawn  from  IISS  User's  Manual,  p.  3-9. 
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The  user  then  types  the  classification  and  caveat  into  the  appropriate  portion 
of  the  form.  The  new  classification  header  then  appears  in  SAs  1  and  4  for  the 
remainder  of  th.e  terminal  session.  During  the  session,  the  analyst/user  is 
responsible  for  ensuring  that  the  classification  header  is  consistent  with  the 
classification  of  data  being  used. 

Send  Message  to  Other  Users  (USER  MESSAGE  Option) 

IISS  allows  its  users  to  send  messages  to  other  users  who  are  logged  onto 
the  IISS  .system.  Users  initiate  this  capability  by  light-penning  the  USER 
MESSAGE  option  on  the  MASTER  MEnU.  The  results  in  display  cf  a  user  message 
form  (Figure  D-8)  in  SA  5. 
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Cl  I F 1  CATION 
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-  Y  5  tJUTXST-SUr  5  TTUH--- * 

IJEi _ 

- - 

SWITCHES 

SITE 

/SI: 

RETAIN 

.  m 

OPERATOR 

/CP 

PRIORITY 

/PR:  A 

ALL  USERS 

/AL 

USER  TERMINAL 

/US 

MASTER  TERMINAL 

/MT 

SPOOL  TO  PRINT0 

/SP 

V _ _ _ _ J 


Figure  D-8.  Format  of  the  USER  MESSAGE  Preformatted  Display.  Redrawn  from 
IISS  User's  Manual,  p.  3-10. 

The  user  controls  message  dissemination  and  retention  by  filling  in  the 
appropriate  blanks  of  the  message,  including  use  of  me P" age  .creation  switches 
listed  at  the  bottom  of  the  form: 

1.  /SI : —  identifies  the  site  to  which  the  conqolet.ed  message 
is  to  be  sent. 

2.  /OP: — specifies  that  the  console  operator  at  a  particular 
site  is  to  receive  the  message. 


s 
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3.  /AL — indicates  that  all  users  at  the  specified  site  are  to 
receive  the  message. 

4.  /MT — indicates  that  the  MASTER  TERMINAL  at  the  specified 
site  is  to  receive  the  message. 

5.  /RE — indicates  that  the  message  should  be  saved  for  a  user 
not  currently  logged  on  to  IISS. 

6.  /PR: — specifies  the  message  priority  assigned  by  the  user. 

7.  /US — indicates  that  the  input  will  come  from  the  user  terminal. 

8.  /SP — indicates  that  the  message  is  to  be  spooled  to  the  printer. 

Incoming  messages  are  displayed  in  SA  3.  The  timing  of  the  incoming 
message  display  depends  on  the  priority  of  the  message.  Low  priority  messages 
appear  when  the  recipient  completes  work  on  the  current  statement  or  menu 
option.  High  priority  messages  interrupt  current  processing.  Users  may  move 
the  screen  cursor  to  SA  3  to  page  through  multi-page  messages,  or  to  print 
the  message  on  am  appropriate  hard  copy  output  device. 

Connect  to  GIM  Language  Capabilities  (GIM  Option) 

Selecting  this  option  results  in  a  system  request  to  sign  on  to  a  GIM 
data  base  (Figure  D-9) .  Completing  this  signon  results  in  display  of  the 
GIM  menu.  Since  there  are  many  complex  capabilities  contained  on  this  menu, 
discussion  of  GIM  options  and  interaction  is  contained  in  a  separate  sub¬ 
section  beginning  on  page  .  ’> 

Connect  to  EUCOM  AIDES  H-6000  (TSS  Option) 

Selection  of  the  TSS  option  causes  page  1  of  the  Honeywell  Signon  dia¬ 
logue  form  (Figure  D-10)  to  appear  in  SA  2,  and  page  2  of  that  form  (Figure 
D-ll)  to  appear  in  SA  5*  The  user  fills  out  page  1  of  this  form  to  gain 
access  to  the  H-6000  Time  Sharing  System  (TSS) ;  the  validated  user  entries 
appear  on  page  2 .  This  option  cannot  be  employed  by  users  who  are  not  famil¬ 
iar  with  TSS  interaction  language,  since  no  information  on  TSS  procedures  is 

1 

available  in  IISS.  Two  variable  function  keys  on  the  SU  1652  are  allocated 
specifically  to  TSS  activities; 

1.  $*BRK  interrupts  H-6000  output  to  the  SU  1652. 

2.  $*DIS  disconnects  the  Honeywell  H-6000  program  in  progress. 
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CLASSIFICATION 


***CAVEAT*** 


DATA  BASE  SIGNON 

DATA  BASE  NAME:  TACOfiD  B 

SITE  NAME  :  MS  _ 

PASSWORD  : 


V, _ _ _ / 

Figure  D-9.  Format  of  the  DATA  BASE  SIGNON  Preformatted  Display.  Redrawn 
from  riSS  User's  Manual,  p.  3-35. 


CLASSIFICATION  ***CAVEAT*** 

TERMINAL  A3 
USERID  $  PASSWORD 
IOENT? 

CLASSIFICATION  OF  YOUR  OUTPUT? 
CLASSIFICATION  OF  FILES  YOU  WILL  CREATE? 
SYSTEM? 


Figure  D-lO.  Format  of  page  1  of  the  Honeywell  Signon  Dialogue.  Redrawn 
from  IISS  User's  MaxmaJ.,  p.  3-14. 


CLASSIFICATION  ***CAV£AT*«* 

TERMINAL  AB  ... 

{PRINT  INHIBIT)  {USERID  $  PASSWORD) 

(standard  wwnccs  ident  IMAGE) 

{3-CHARACTER  WWMCCS  CLASSIFICATION  CODE) 

{3-CHARAC-TER  WWi.CCS  CLASSIFICATION  COCE) 

(ANY  OF  THE  HIS  SUBSYSTEM,  I.E.,  CARDIN,  EDIT,  JOUT,  ETC.) 


Figure  D-ll.  Format  of  p.  2  of  the  Honeywell  signon  Dialogue.  Redrawn  from 
IISS  User's  Manual,  p.  3-15. 

Transferring  Large  Amounts  of  Data  (BDT  Option) 


Selecting  the  BDT  option  cuases  the  bulk  data  transfer  (BDT)  form 
(Figure  D-12)  to  appear  in  SA  2 .  This  function  is  used  in  transferring 
relatively  large  amounts  of  data  from  terminal  to  terminal  or  from  disk  file 
to  disk  file.  The  analyst/user  identifies  the  output  (recipient  of  data) 
and  input  (provider  of  data)  information  in  the  space  provided.  Space  is 
provided  for  terminal  text  input  to  texplain  the  reason  ,for  and  content  of 

■I  1 

the  bulk  data  transfer.  Specification  of  input  and  output  may  include  one 
or  more  switch  options:  J 

1.  /SI — specifies  site  name^. 

2.  /FI — indicates  that  th^  preceding  entry  is  a  file  specifi¬ 
cation;  used  to  distinguish  file  names  from  user  names. 

3.  /LB — specifies  the  type  of  label  for  a  magnetic  tape; 
legal  values  (net  presented  to  the  user)  are: 

l 

a..  BL — bypass  label, 

fc.  SL — standard  label, 

c.  NL — no  label. 

4.  /AP — appends  the  bulk  data  transfer  to  an  existing  specified 
file. 
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CLASS  in  CAT  I  ON 


***CAVEAT*** 


BULK  DATA  TRANSFER  (FILE-TO-FllE) 

OUTPUT: 

INPUT  :  “ 

USE  TH  t  S’  5Mfcr  F0!T  THWWOEXT  TnFuT: - 


SWITCHES 


SITE 

/SI: 

REOPEN  /RO 

RECORD  SIZE 

/RS:XXXX 

FILE 

•  /FI 

SUPERSEDE  /SU 

MAG  TAPE  FILE 

/TP 

LABEL 

/L8:XXXXXXXX 

USER  INPUT  /US 

RECORD  FORMAT 

/RF-.XX 

APPENO 

/AP 

BLOC'-'.  SIZE  /BS: XXXX 

FOREIGN  TAPE  FILE 

/TF 

UPDATE 

/UP 

TAPE  VOLUME  /VL‘XXXXXX 

V _ _ _  J 


Figure  D-12 .  Format  of  the  Bulk  Data  Transfer  (BDT)  ^reformatted  Display. 
Redrawn  from  IISS  User's  Manual,  p ,  3-15. 


5.  /UP--indicates  that  an  existing  version  of  an  output 
(recipient)  file  is  to  be  updated. 

6.  /RO — indicates  that  a  continuation  file  is  to  be  re¬ 
opened. 


7.  /SU--.indicates  that  an  existing  version  of  the  output 
(recipient)  file  is  to  be  superseded;  the  version  number  * 
of  the  file  must  be  explicit. 

8.  /US — indicates  that  input  for  the  bulk  data  transfer  will 
come  from  the  user  terminal;  distinguishes  terminal  input 
from  file  input. 


9.  /BS : n — specifies  the  block  size  for  tape  or  disk  file;  the 

default  size  (not  displayed  to  the  user)  is  512  blocks. 

10.  /VL: n — specifies  the  volume  label  for  magnetic  tap.e  . 

11.  /RS:n — specifies  the  record  size. 


12.  /RF:zz — specifies  record  format  for  bulk  data  transfer  output 

files;  legal  values  (not  displayed  to  user)  are: 


a. 

VA — variable 

span. 

b. 

VB — variable 

blocked. 
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c. 


FL — fixed  length. 


d.  FB— fixed  block. 

14.  /TF— indicates  that  the  tape  file  is  a  foreign  tape  file. 

The  analyst  terminal  automatically  returns  to  the  MASTER  MENU  when  the  bulk 
data  transfer  is  completed. 

Execute  a  Batch  Job  on  the  EUCQM  AIDES  H-6000  ( RJE  Option) 

When  the  RJE  option  is  selected,  the  Remote  Job  Entry  (RJE)  form  (Figure 
C-13)  appears  in  SA  2.  Much  as  in  the  BDT  situation,  the  user  enters  input 
and  output  specifications  in  the  appropriate  blanks  in  the  form.  The  input 
required  in  the  DATANET  ID  field  was  not  specified  in  IISS  literature. 

Because  the  RJE  specification  must  include  Job  Control  Language  (JCL) ,  the 
user  must  have  some  familiarity  with  Honeywell  JCL  to  enter  a  remote  job. 

IISS  does  not  provide  any  information  to  help  its  users  to  generate  JCL  cards 
or  file  records. 


classification  ***caveat**» 

REMOTE  JOB  ENTRY 

OUTPUT : 

INPUT  :  "  ~  "  ~ " 

DATANET  "ID-:™  _ 

SWITCHES 


•FILE  /FI 

•LABEL  /LB:XXXXXXXX 

♦APPEND  /AP 

♦UPDATE  /UP 

*  REOPEN  /RO 

♦PRIORITY  /PR:  A 

♦  SUPERSEDE  /SU 


•BLOCK  SIZE  /BS.'XXXX 

•TAPE  VOLUME  /VL:NNNNNN 

♦RECORD  SIZE  /RS:XXXX 

•RECORD  FORMAT  /RF:XX 

•MAG  TAPE  FILE  /.TP 

♦SPOOL  TO  PRINT  /SP 

•FOREIGN  TAPE  FILE  /TF 


♦OUTPUT  ONLY 

•ALLOWABLE  FOR  OUTPUT  AND  INPUT 


Figure  D-13.  Format  of  the  Remote  Job  Entry  (RJE)  Preformatted  Display. 
Redrawn  from  IISS  User's  Manual,  p.  3-17. 

Completing  the  input  and  output  RJE  specifications  requires  the  use  of 
various  switches.  These  incJude: 


1. 


/FI — indicates  that  the  preceding  entry  is  a  file  name, 
rather  than  a  user  I.D. 


2,  /LB — specifies  the  type  of  label  for  a  magnetic  tape; 

legal  values  (not  presented  to  the  user)  ares 

a.  BL — bypass  label. 

b.  SL — standard  label. 

c.  HL— -no  label. 

2 .  /A?' — appends  the  RJE  output  to  an  existing  specified 

file. 

4.  /UP — indicates  that  an  existing  version  of  an  output 
(recipient)  file  is  to  be  updated. 

5.  /RO — indicates  that  a  continuation  file  is  to  be  re¬ 
opened  . 

6.  /SU — indicates  that  an  existing  version  of  the  output 
(recipient)  file  is  to  be  superseded,  the  version  number 
of  the  file  must  be  explicit. 

7.  /BS:n — specifies  the  block  size  for  tape  or  disk  files,-  the 
default  size  (not  displayed  to  the  user)  is  512  blocks. 

8.  /VL ;n — specifies  the  volume  label  for  magnetic  tape. 

9.  /RS.-n — specifies  the  record  size. 

10.  /RP : xx — specifies  record  format  for  output  files;  legal 
values  (not  displayed  to  the  user)  are: 

a .  VA — variable  spar. . 

b.  VB~variable  blocked. 

c.  FL — fixed  length. 

d.  FB--fixed  block. 

11.  /TP — indicates’  that  the  file  is  a  magnetic  tape  file;  used 
to  distinguish  tape  from  disk  files. 

12.  /SP--indicates  that  output  is  to  be  spooled  to  a  print  file. 

13.  /TF — indicates  a  foreign  tape  file. 

14.  /PR — identifies  priority  of  transaction. 


Wnen  the  user  presses  the  SEND  key,  the  Honeywell  6000  executes  the  RJE 
task  and  completes  the  job.  The  MASTER  MENU  file  is  automatically  displayed 
at  the  SU  1652 . 


Selection  of  the  IN  ANAL  option  results  in  the  appearance  of  the  Input 
Analvst  File  Selection  display  (Figure  D-14) . 


Figure  D-14.  Format  of  the  Input  Analyst  (IN  ANAL)  File  Selection  Prefor¬ 
matted  Display.  Redrawn  from  IISS  User's  Manual,  p.  3-19. 

The  user  then  light  pens  one  of  the  two  options  on  the  form.  Selection  of 
ACCESS  AN  EXISTING  file  indicates  that  a  partially  completed  JINTACCS  message 
already  exist-s?  the  user  in  then  required  to  enter  a  complete  file  name  or  a 
(if  the  UIC  is  nther  than  (10,10))  complete  file  specification.  The  user 
then  completes  the  JINTACCS  message  without  the  MMJ  form  support  provided 
for  creation  of  a  new  JINTACCS  message. 

a  . 

Selecting  the  CREATE  A  NEW  FILE  option,  the  system  displays  the  IN  ANAL 
dissemination  header  (Figure  D-15)  in  SA  2.  The  EXPLICIT  ADDRESSEE (s) 
field  must  be  filled  in  by  the  user.  The  other  fields  in  this  form  are 
optional,  being  used "to  define  further  the  dissemination  of  the  completed 
message.  The  user  must  also  light-pen  one  of  the  JINTACCS  message  format 
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designations.  This  results  in  the  display  of  a  blank  JINTACCS  message  form 
(such  as  the  one  presented  in  Figure  D-1S)  in  SA  2 .  The  user  fills  in  the 


’  ■  “  - - -  - - \ 


CLASSIFICATION  ***CAVEAT*** 


DISSEMINATION  HEADER 

EXPLICIT  ADDRESSEE(S) :  -  -  . . 

'SEPARATE  wr:-!  COMMAS  I . . 


ACTIVITY:  MESSAGE  TYPE: 

TYPE  :  . 

LOCATION:  .  PRIORITY  : 

OTG  :  . 

JNIT  :  -  --  -- RETENTION  : 

AVAILASLE  JINTACCS  MESSAGE  FORMATS 
RII  JPSRR  TACREP  TGTINFCREP 

RRII  INTkCP  SENREP  MI J 1  FEEDER 

D!  SIM  IliTSOil  TAR3UL  OTACARSREQ 

JRSPR  MISP.EP  TACELINT  HOTPHOTOREP 

JNP128  MISREP 


V-..  _ J 


Figure  D-15.  Format  of  the  Input  Analyst  (IN  ANAL)  Dissemination  Header  Pre 
formatted  Header  Prsformatted  Display.  Redrawn  from  IISS  User's  Manual, 
p.  3-20. 


Figure  D-16.  Format  of  the  Input  Analyst  (IN  ANAL)  JINTACCS  Preformatted 
Display.  Redrawn  from  TISS  User's  Manual,  p.  3-20. 
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format  to  complete  the  JINTACCS  message.  It  should  be  noted  that  the  IISS 
system  contains  no  information  about  the  legal  values  or  formats  permissible 
for  any  of  the  fields  in  the  JINTACCS  dissemination  header  (Figure  D-15)  or 
the  JINTACCS  formats  themselves  (example  in  Figure  D-16) .  For  information  on 
codes  and  abbreviations,  the  user  must  consult: 

Intelligence  Information  Subsystem  Datalog  of  Authorized  Data 
Elements  and  Codes,  Second  Revision,  Data  Element  Index,  TRW 
Document  No.  285O3-W081-RU-00 . 

This  document  reference  is  not  referenced  at  the  terminal. 

When  the  user  has  finished  completing  the  JINTACCS  message,  the  END- 
INPUT  ANALYSIS  (Figure  D-17)  is  called  up  by  pressing  the  END  MSG  VFK. 


Figure  D-17.  Format  of  the  Input  Analyst  (IN  ANAL)  End-Input  Analysis  Pre¬ 
formatted  Display.  Redrawn  from  IISS  User’s  Manual,  p.  3-21. 

If  the  message  has  been  completed,  the  user  enters  "Y"  in  the  first  field  of 
the  form.  This  causes  the  message. to  be  disseminated  to  uhe  appropriate 
recipients.  If  the  user  has  been  unable  to  complete  the  massage,  or  if 
for  some  other  reason  he/she  does  not  wish  immediate  dissemination,  a  "N" 
is  entered  in  the  DISSEMINATOR  field.  To  save  the  message  for  subsequent 
dissemination  or  completion,  the  user  must  enter  a  file  specification. 
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Bypass  Intel1 igence  Features  of  SU  1652  (TELETYPE  Option) 


Selecting  the  TELETYPE  option  from  the  MASTER  MENU  does  not  result  in 
display  of  any  additional  menus  or  forms ,  since  the  TELETYPE  option  bypasses 
the  MM I  features  normally  available  for  IISS  operations.  In  essence,  the 
TELETYPE  option  puts  the  user  terminal  into  "dual  screen  teletype  mode," 
with  user  input  accepted  in  SA  2 ,  and  output  provided  in  SA  5 .  The  TELETYPE 
mode  provides  the  user  with  access  to  all  IISS  features  available  from  the 
MASTER  MENU,  but  requires  that  the  user  remember  an  interaction  language. 
Commands  for  the  various  functions  are  presented  in  Table  D-i.  if  the  user 
is  working  with  an  SU  1652,  the  at  the  end  of  each  command  may  be  deleted. 
(Apparently  the  TELETYPE  mode  allows  terminals  other  than  the  SLT  1652  to 
control  IISS  operations.) 

Available  IISS  documentation  does  not  indicate  how  the  IN  ANAL  and  PLOT 
options  (available  via  the  .'1ASTEP.  MENU)  can  be  exercised  in  TELETYPE  mode. 
Apparently  the  JINTACCS  formats  can  be  entered  directly  on  an  SU  1652  terminal 
to  duplicate  the  IN  ANAL  function;  it  is  doubtful  that  this  function  can  be 
implemented  through  terminals  other  than  the  SU  1652 .  The  status  of  the  PLOT 
option  in  TELETYPE  mode  is  unknown. 

GIM  Menu  and  GIM  Language  Options 

These  options  result  from  selecting  the  GIM  option  from  the  IISS  MASTER 
MENU.  The  basic  purpose  of  the  GIM  options  is  to  interact  with  the^,  order- 
of-battle  data  bases  stored  in  IISS  under  Generalized  Information  Management 
(GIM)  control.  They  provide  the  capability  to  modify,  add,  to  ana  query 
the  data  bases,  as  well  as  to  generate  ad  hoc  reports  based  on  those  data. 

The  first  screen  (form)  which  appears  after  selecting  the  GIM  option 
is  the  Data  Base  Signon  form  (Figure  D-18) ;  this  form  appears  in  SA  5 .  The 
user  must  enter  a  logal.  IISS  GIM  data  base  in  the  DATA  BASE  NAME  field;  the 
site  code  (for  the  MIC,  MRIT-S,  or  MRIT-L)  in  the  SITE  NAME’ field,  and  a 
valid  password  in  the  PASSWORD  field,  if  these  three  items  are  entered 
correctly,  the  GIM  MENU  (Figure  D-19)  appears  in  SA  2 . 

There  are  five  core  options  available  from  the  GIM  MENU: 

1.  GIM  LANGUAGE,  which  permits  the  user  to  enter  commands 
directly  in  GIM  language. 
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aaa  to  user  terminal . 


/* 


■\ 


CLASSIFICATION  ♦••CAVEAT*** 

DATA  BASE  SIGNON 


DATA  BASE  NAME:  T  A  C  0  B  0  8 

SITE  MAf.E  :RS - 

PASSWORD  : 


V. 


Figure  D-18.  Format  of  the  GIM  Data  Base  Signon  Form.  Redrawn  from  IISS 
User's  Manual,  p.  3-35. 


r 


classification 


••'CAVEAT*** 
GIM  MENU 

ANALYSIS 


INPUT 


GTH  LANGUAGE 

EUNITS 

ACTF 

EUNITS 

ACTF 

UTM-GEO 

AUNTF 

PLATF 

AUNTF 

PLATF 

REPuRTW 

EOBF 

ESYSF 

EOBF 

ESYSF 

PERSNF 

K3LF 

PERSNF 

MSLF 

RI  IF 

PPTGT 

b:  if 

PPTGT 

INSTF 

ARFLUr 

ACTIVN 

RWYF 

INSTF 

ARFLDF 

TRANSLATE 

RWYF 

COLUMN  *1  FOR  USE  WITH  ALL  DATA  BASES. 

COLUMNS  and  *5  FOR  USE  WITH  THE  TAC08  DATA  BASE  ONLY 


V 


J 


Figure  D-19.  7  <j  GIM  MENU.  Redrawn  from  IISS  User's  Manual,  p.  3-36. 
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2.  UTM-GEO,  which  3upport3  conversion  among  geocoordinate  systems. 

3.  REPORTW,  which  allows  the  user  to  define  ad  hoc  report  formats. 

4.  ANALYSIS,  which  permits  the  user  to  query  the  order-of-b<rctle 
data  bases. 

5.  INPUT,  which  permits  the  user  to  enter  new  records  into  the 
order-of-battla  data  bases. 

The  available  IISS  documentation  does  not  specify  how  these  options  are 
selected;  ..t  is  assumed  that  the  light  pen  is  used.  Detailed  discussions  of 
each  option  are  presented  below. 

Enter  Commands  Directly  in  GIM  Language  (GIM  LANGUAGE  Option) 

Light -perming  the  GIM  LANGUAGE  option  from  the  GIM  MENU  permits  the  user/ 
analyst  to  access  GIM  data  files  directly.  While  the  GIM  LANGUAGE  option  is 
supported  by  forms,  these  are  apparently  not  nearly  so  sophisticated  as 
those  associated  with  other  GIM  MENU  options.  Therefore,  the  user  must  be 
conversant  with  GIM  language  grammar  and  syntax.  Grammatical  elements  of  the 
GIM  language  are  presented  in  Appendix  B;  a  complete  description  of  GIM 
language  is  available  in  three  documents: 

1.  GIM- I I  Basic  Users  Manual  (TRW-6760-WS21-RU-00) . 

2.  GIM-II  Advanced  Users  Manual  (TRW-676J3-W522-RU-00)  . 

3.  BR-1538A  (T50)  and  BR-1538B  (T80>  Installation  and  Operation 
TM  (TM-DD-1538-2AB) . 


$ 
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Project  personnel  did  not  have  the  opportunity  to  review  these  documents. 

GIM  commands  are  entered  in  the  input  form  displayed  in  SA  2;  output  appears 
in  SA  5 . 

Geographic  Coordinate  Conversion  (UTM-GEO  Option) 

Users  may  convert  between  Universal  Transverse  Mercator  (UTM)  Military 
Grid  Reference  System  and  geographic  coordinates  (latitude/iongitude) : 

•  < 

i.  UTM-to-Geographic  coordinate  conversion.  The  IISS  user  enters 
the  sphereoid  and  the  UTM  coordinates?  geographic  coordinates 
are  calculated  and  displayed. 

2  .  geographic  coordinates-to-UTM  conversion.  The  IISS  user  enters 
the  latitude  and  longitude?  UTM  coordinates  and  spheriod  are 
calculated  and  displayed. 
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Both  conversions  are  performed  by.  filling  in  the  appropriate  sections  of  the 
display  in  Figure  D-20. 


CLASSIFICATION 


•••CAVEAT*** 


UTM-GEO  CONVERSION 

SPHER0I0: _  UTM : _ 

GEO: _ 


Figure  D-20.  Format  of  the  UTM-GEO  Conversion  Form.  Redrawn  from  IISS 
User's  Manual,  p.  3-37. 

Report  Format  Specification  (REPQRTW  Option) 

IISS  permits  the  user  to  define  the  format  and  content  of  output  based 
on  IISS  file  holdings.  Specifications  permitted  include: 

1.  Number  of  lines  per  page  (maximum  of  60) . 

2.  Line  width  (maximum  of  132  characters). 

3.  Heading  lines  (literal  stings;  free  text  input)  . 

4.  Footing  lines  (literal  strings;  free  text  input) . 

5.  Column  heading. inclusion/suppression. 

6.  File  to  be  use^. 

7.  Data  elements  or  variables  from  the  file  to  be  included. 

The  first  five  types  of  report  specification  are  entered  on  page  1  of  the 
REPORTW  forms  (Figure  D-21) . 
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Figure  d-21.  First  Page  of  the  Report  Writer  (REPORTW)  Preformatted  Display. 
Redrawn  from  -Z3S  User's  Manual,  p.  3-39. 

the  User  may  eiect  to  skip  this  page  of  specification  and  accept  the  GIM 
REPORTW  format  defaults.  There  is  no  on-screen  indication  of  this  default 
capability,  nor  is  there  any  example  of  the  appearance  of  the  default  format. 


The  second  page  of  the  REPORTW  format  (Figure  D-22)  cannot  be  defaulted, 
since  it  is  used  to  specify  the  file  and  associated  variables  to  be  used  in 
producing  the  report. 


Figure  D-22.  decond  Page  of  the  Report  Writer  (REPORTW)  Preiormatced  Display 
Redrawn  from  IISS  User's  Manual,  p.  3-39. 


The  user  completes  the  FILE  NAME  portion  of  the  form,  and  then  enters  the 
SELECTION  CLAUSE.  Users  must  enter  attribute  names  consecutively  on  the  form 
in  the  SELECTION  CLAUSE  section. 

The  IISS  User's  Manual  mentions  that  the  REPORTW  option  includes  basic 
capabilities  for  "page  numbering,  positioning  data  on  a  print  line,  sorting, 
and  summarizing  a  report"  (p.  3-38) .  However,  there  is  no  explanation  in  the 
report  of  how  to  perform  these  functions,  if  they  are  indeed  controllable  by 
the  user.  Examination  of  the  training  materials  developed  for  the  IISS 
involvement  in  exercise  ABLE  ARCHER  indicates  that  the  following  functions 
may  be  performed  within  the  REPORTW  option: 

1.  Attribute  name  specification. 

2.  Label  specification. 

2.  Justification  selection  (right  or  left) . 

4.  Sort  specification  (ascending  or  descending) . 

5.  Sort  level  specification. 

6.  Field  width. 

The  training  materials  suggest  that  these  specifications  must  be  entered  in 
an  appropriate  format,  but  no  prompting  or  help  is  provided  to  the  user/ 
operator . 

Retrieval  of  Qrder-of-Battle  Data  (ANALYSIS  Option) 

To  retrieve  data  from  an  order-of -battle  (TACOB)  data  base,  the  analyst 
light-pens  one  of  the  file  names  listed  under  the  ANALYSIS  heading  in  the  GIM 
MENU  (Figure  D-23) .  Currently,  the  files  supported  by  IISS  are  limited  to 
the  following: 


1. 

EUNITS 

(Ground  order-of-battle) . 

2. 

AUNITS 

(Air  order-of-battle) . 

3. 

ARFLDF 

< 

(Airfields) . 

4. 

ACTF  (Activities) . 

5. 

PERSNF 

(Biographicsl) . 

6. 

PPTGT 

(Preplanned  targets) . 
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Figure  D-2 3 .  The  GIM  MENU.  (Repeated  for  convenience  from  Figure  D-19.) 

7.  RIIF  (Requests  for  intelligence  information). 

8.  RWY  (Runways) . 

9.  INSTF  (Installations). 

A  file  name  having  been  selected,  the  user  must  press  either  the  SELECT  FORM 
or  SELECT  GIM  VTKs; 


1.  Pressing  the  SELECT  FORM  VFK  causes  the  system  to  display' 
a  two-page  form  in  SA  5.  The  first  page  of  this  form  is 
a  "selection/retrieval  screen'1  (Figure  1-24)  .  In  this 
example  (for  the  AUNIF,  Air  order-of --battle ,  file)  ,  the 
user  specifies  the  characteristics  of  the  unit(s)  which 
should  be  analyzed.  In  essence,  filling  in  this  form 
specifies  the  criteria  for  a  retrieval  output  listing. 

The  user  fills  in  the  form  with  the  desired  parameters, 
and  then  displays  an  "index  list"  (Figure  D-25)  of  those 
records  meeting  the  specified  criteria.  The  index  list 
summarizes  the' information  for  the  records  meeting  the 
retrieval  criteria.  In  this  example,  the  index  list  con¬ 
tains  the  following  information: 

a.  The  unit  I.  D.  Number  (AUNIF). 

b.  The  parent  I.  D.  number  (PUNIT) ,  which  is  the 
transliterated  unit  name  or  official  identification 

of  the  unit  responsible  for  administrative/ operational 
control  of  the  unit. 
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c.  The  number  of  equipments  authorized  (EQATH)  in 
correlation  with  the  aircraft  type. 

d.  The  actual  number  of  aircraft  (EQPOH)  of  a 
particular  type  on  hand. 

e.  The  function  of  the  aircraft  (ACFIF) . 

f.  The  total  persons  authorized  (PRTOT)  in  the  unit. 

g.  The  foxhole  total  (FHTOT)  for  the  unit. 

h. .  CALEG,  a  code  name  not  referenced  or  described  in 

the  "TACOB  Data  Base  Users  Guide." 


The  documentation  reviewed  does  not  discuss  whether  users  can 
control  the  format  or  content  of  index  list  displays.  Such 

a  capability  might  be  useful,  such  as  in  displaying  the  equip¬ 
ment  type . 
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Figure  D-24.  Format  of  the  SEI.ECTION/RETRIEVAL  SCREEN  preformatted  Display 
from  the  ANALYSIS  Function.  -Redrawn  from  IISS  User's  Manual,  p.  3-41. 

After  reviewing  the-  index  list,  the  analyst  may  select  an 
individual  record  for  more  detailed  scruting  by  light-penning 
a  record  I.D.  in  the  INDEX  LIST.  When  IISS  is  fully  operational 
this  will  result  in  page  1  of  a  FULL  PECORD  DISPLAY  (Figure  D-26) 
appearing  in  SA  5.  Pressing  the  NEXT  PAGE  FFK  brings  up  the 
second  page  of  the  FULL  RECORD  DISPLAY  (Figure  D-27) ,  and 
pressing  it  again  results  ir.  display  of  the  third  page 
of  the  FULL  RECORD  DISPLAY  (Figure  D-28) .  These  three  pages 
contain  all  of  the  information  alxmt  the  selected  record. 
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Figure  D-25 .  Example  of  an  INDEX  LIST  from  the  ANALYSIS  Function.  Redrawn 
from  IISS  User's  Manual,  p.  3-42. 


As  it  is  currently  configured,  the  IISS  does  not  include  full 
record  displays-.  According  to  the  IISS  User's  Manual. 


For  the  initial  fielding  of  the  FMS,  the  form  FULL 
RECORD  Displays  will  not  be  implemented .  In  its 
place  will  be  a  GIM-II  list  record  format,  (p.  3-42.) 


The  "GIM-II  list  record  format”  was  not  provided  in  the  docu¬ 
mentation  available  to  the  Synectics  project  staff.  The  •. 
typical  GIM-H  listing  is,  however,  linear,  with  the  tabula¬ 
tion  simply  presenting  attribute  (variable)  values  as  they 
occur  in  the  GIM-II  data  set  definition. 


Pressing  the  SELECT  GIM  left  VFK  causes  the  system  to  display: 


...a  form  to  be  completed  that  requires  some  previous 
knowledge  of  the  GIM-II  statement  syntax.  The  user 
may  construct  the  GIM  statement  on  this  form ,  up  to, 
but  not  ipcluding,  the  LIST  verb  and  then  strike  the 
SEND  key.  The  system  replies  by  presenting  him  with 
an  INDEX  $IST  as  mentioned  in  the  Form  Selection  Pro¬ 
cedure  ...  (IISS  User's  Manual,  p.  3-41). 
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Figure  d-26.  Page  i  of  a  Full  Record  Display  (FRD)  front  the  ANALYSIS 
Function.  Redrawn  from  IISS  User's  Manual,  p.  3^43. 
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Figure  D-27.  Page  2  of  a  Full  Record  Display  (FRD)  from  the  ANALYSIS 
Function.  Redrawn  from  IISS  User's  Manual,  p.  3-43. 
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Figure  D-28.  Page  3  of  a  Full  Record  Display  (FRD)  from  the  ANALYSIS  Function. 
Redrawn  from  TISS  User's  Manual,  p.  3-43. 

The  documentation  available  to  Synectics  does  not  indicate  what 
the  appropriate  GIM  formats  are,  nor  what  the  format  of  the 
entry  form  is.  After  the  retrieval  specification  has  been 
entered,  however,  the  data  retrieval  and  review  process  pro¬ 
ceeds  in  the  same  manner  as  when  the  Selection/Retrieval  Screen 
was  used  (i.e. ,  INDEX  LIST  appears,  the  analyst  selects  one  of 
the  records  using  the  light  pen,  and  the  content  of  that  record 
is  displayed) . 

Input  of  Order-of-Battl e  Data  (INPUT  Option) 

Input  of  order-of-battle  data  is  achieved  in  much  the  same  way  as  retrieval 
of  order-of-battle  data,  except  that  Selection/Retrieval  Screens  and  Index 
Lists  are,  of  course,  not  displayed.  After  light-penning  the  desired  file 
appearing  under  the  INPUT  heading  on  the  GIM  menu  the  user/analyst  is  pre¬ 
sented  with  a  blank  FULL  Record  Display  in  three  pages  as  in  Figures  D-26, 

D-27,  and  D-28.  To  add  a  new  record  to  any  existing  file,  the  user  fills  in 
the  appropriate  blanks  in  the'  full -record  format  and  presses  the  SEND  FFK. 

The  user  is  then  supposed  to  "check  the  statement  appearing  in  SA  6  ( IISS 
User's  Manual,  p.  3-45),  although  no  indication  of  what  the  user  is  supposed 
to  check  for  appears  in  the  User's  Manual. 
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Updating  Order'-of-Battle  Data  (ANALYSIS  Option;  DtjPPATE  Option) 

In  addition  to  retrieving  individual  oider-of-battle  records  and  adding 
new  ones,  the  analyst  using  IISS  may  wish  to  change  the  attributes  of  exist¬ 
ing  records  (i.e.,  update  the  existing  record).  At  the  time  the  available 
user  documentation  was  written,,  there  wa3  no  convenient  way  to  update  indi¬ 
vidual  records.  Update  was  accomplished  using  a  routine  known  as  DUPDATE. 

Since  this  was  (or  is)  a  temporary  situation,  the  user  interaction  involved 
in  using  DUPE ATE  is  not  detailed  here.  This  discussion  focuses  on  the  forms- 
driven  update  process  which  was  planned  for  implementation  on  the  IISS  et 
the  time  when  the  user's  manuals  were  written. 

The  IZ5S  User's  Manual  is  unclear  about  how  updates  are  actually  made. 
Apparently  the  analyst  light^pens  the  desired  file  in  the  ANALYSIS  column, 
light -pens  the  desired  record  from  the  INDEX  LIST,  and  thus  receives  either 
the  FULL  RECORD  DISPLAY  or  the  GIM-II  full  record  listing  (depending  on 
whether  the  SELECT  GIM.ar  SELECT  FORM  VFK  was  pressed) .  Whether  the  analyst 
merely  "cver-writes"  the  displayed  information  to  make  the  change,  or  performs 
some  other  activity,  is  unclear  from  the  available  documentation.  It  should 
be  noted,  however,  that  updates  can  be  performed  directly  using  the  GIM  language. 

Defining  Geographically  Oriented  Searches  (ANALYSIS  Option) 

In  addition  to  defining  retrievals  on  the  basis  of  the  values  of  record 
attributes,  the  analyst  may  define  two  types  of  geographically  ordered  search 
definitions:  circle  searches  (i.e.,  all  locations  within  n  distance  units 
from  a  given  location)  and  polygon  searches  (i.e.,  all  locations  within  a 
closed  polygon  defined  by  the  user) . 

Polygon  searches  are  specified  by  first  proceeding  as  though  an  ordinary 
retrieval  were  being  performed  using  the  SELECT  FORM  option.  After  the 
Selection/Retrieval  Screen  appears,  the  analyst  presses  the  NEXT  PAGE  FFIC. 

This  causes  the  POLYGON  SEARCH  form  (Figure  D-29)  to  appear  in  Sa  5.  The 
analyst  has  two  options:  ' 

1.  If  a  previously  stored  file  of  geographic  points  exists,  the 
user  may  enter  the  appropriate  file  name  in  the  PTCOM$  FILE 
ID  (STORED  IS  NAME)  field. 
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POLYGON  SEARCH 


PICONS  FILE  ID  (STORED  10  NAME): 
INPUT  POINTS  (IN  ORDER,  CLOCKWISE): 


/ 

Figure  D-29.  Format  of  the  Polygon  Search  Form  is  the  ANALYSIS  Function. 

Redrawn  from  IISS  User's  Manual,  p.  3-44. 

2.  If  a  file  of  points  does  not  exist,  the  user  may  enter 
geographic  points,  in  order  clockwise,  into  the  appro¬ 
priate  place  on  the  POLYGON  SEARCH  form. 

The  user  may  save  the  specified  points  for  subsequent  polygon-defined  retriev¬ 
als  by  entering  a  file  name  in  conjunction  with  the  specified  geographic 
points.  Up  to  20  points  may  be  entered.  Existing  documentation  does  not 
indicate  whether  the  last  point  entered  is  automatically  connected  to  the 
first,  or  the  last  point  must  be  entered  exactly  as  the  first. 

Inspection  of  the  training  materials  prepared  for  participants  in 
exercise  ABLE  ARCHER  indicate  that  it  is  possible  to  define  a  polygon  search 
without  employing  the  SELECT  FORM  option  in  ANALYSIS.  This  method  apparently 
employs  the  GIM  language  capability  of  IISS,  with  the  polygon  specification 
as  follows : 

For  <<file  content  specif ication»  with  $P0LY  (GEOLO,  «coordinate  1, 
coordinate  2,....,  coordinate  n"  using  this  technique: 

1.  The  polygon  must  consist  of  at  least  3  points,  and  may  con¬ 
sist  of  as  many  as  13  points. 

2.  Points  must  be  entered  in  clockwise  or  counter  clockwise 
fashion. 
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3.  End  points  must  connect .  (NOTE:  it  is  assumed  that  this 
means  that  the  start  points  and  end  points  must  be  identi¬ 
cal . ) 

XXSS  also  provides  the  users  with  the  capability  to  define  circle 
searches.  This  capability  is  apparently  not  available  within  the  SELECT  FORM 
option  of  analysis,  but  is  rather  employed  as  a  feature  of  the  GXM  language. 
Three  types  of  circle  search  definitions  are  possible: 

1.  To  define  a  search  within  a  circle,  a  command  in  the  follow¬ 
ing  format  is  entered: 

For  «unit  specification >>  with  $DXSTM  (GEOLO,  "geo-coord”) 

LT  "#meters"  LIST 

2.  To  define  a  searcn  outside  of  a  circle,  a  command  in  the 
following  format  is  entered: 

For  «unit  specif ication>>  with  $DISTM  (GEOLO,  "geo-coord") 

GT  "#meters"  LIST 

3.  To  define  a  banded  region  around  a  point,  a  command  in  the 
following  format  is  entered: 

For  «unit  specif ication»  with  $DISTM  (GEOLO,  "goo-coord") 

GT  #2xmeters"  LIST 

Switches  are  available  for  three  distance  scales: 

1.  $DISTM$  =  distance  in  meters 

2 .  $DISTNM$  *  distance  in  nautical  miles  \ 

3.  $DXSTSM  3  distance  in  statute  miles 
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INTRODUCTION 


One  of  the  primary  purposes  of  IISS  is  to  permit  U.S.  Army  Intelligence 
analysts  to  create,  modify,  and  retrieve  order-of-battle  information.  This 
kind  of  information  describes  friendly  and  enemy  military  organizational  units 
in  terms  of  their  location,  designation,  authorized  strength,  actual  strength, 
associated  equipment  (tanks,  aircraft,  helicopters,  artillery,  etc.),  and 
other  information  necessary  to  tactical  command,  and  control.  Much  of  t'ne 
theoretical  and  practical  utility  of  IISS  is  dependent  on  the  structure  and 
content  of  these  data  bases ,  as  well  as  on  the  nature  and  capability  of  the 
software  used  to  process  the  information  held  in  the  data  bases. 


ORDER-OF-BATTLE  DATA  BASE  STRUCTURES 


Three  order-of-battle  data  base  structures  have  been  or  will  be  associ¬ 
ated  with  IISS.  These  are: 

1.  TACOB  (Tactical  Qrder-of-Battle)  System,  which  is  the  primary 
data  base  structure  incorporated  into  IISS.  The  TACOB  struc¬ 
ture  was  designed  as  the  IISS  order-of-battle  information 
organization  scheme,  and  was  incorporated  into  the  system 
when  it  was  first  fielded. 


ASCOBS  (Army  Standard  Ground  Order-of-Battle  system) ,  a 
peacetime  perspective,  theatre-oriented  ground  order-of- 
battle  structure  developed  with  HQ  USAREUR  as  the  propo¬ 
nent.  This  data  base  structure  was  developed  to  perform 
3  major  functions: 


Fulfill  DoD  delegated  production  (DPD)  requirements. 


b.  Address  European  theatre  ground  order-of-battle  (GOB) 
storage,  maintenance,  and  retrieval  requirements. 

c.  Support  production  requirements  of  the  Deputy  Chief 
of  Staff  £or  Intelligence  (DCSI) . 

ASGOB  is  a  garrison-  and  installation-oriented  structure. 

It  is  therefore  inappropriate  for  wartime  use  because 
military  units  will  not  be  in  garrison.  When  fully  imple¬ 
mented,  interaction  with  ASGOBS  will  be  handled  through  a 
communications  structure  as  depicted  in  Figure  E-l.  At 
the  time  of  the  Synectics/ARI  data  collection  of  USAREUR 
HQ,  the  on-line  access  to  the  ASGOBS  data  base  had  not  yet 
been  fully  implemented.  Fully  operational  data  base  access 
is  to  be  attained  early  in  1981. 
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GOB SR  (Ground  Order-of-Battle  Extract) ,  which  is  a  "one- 
time"  data  base  usad  to  anhanca  the  realism  of  IISS  inter¬ 
action  during  tha  ABLE  ARCHER  exercise.  This  data  baxa 
was  formed  by  extracting  information  from  an  actual  GOB 
data  base,  and  fitting  it  into  a  tailored  TACOB  structure. 

Since  this  data  basa  structure  was  usad  only  once,  it 
will  not  ba  discussed  further  hare. 

Since  tha  TACOB  data  base  structure  is  tha  one  designed  with  IISS  specifi 
cally  in  mind,  and  since  most  of  the  available  documentation  has  a  TACOB  empha 
sis,  the  i-cus  in  this  section  will  be  on  TACOB  information  set  structure  and 
how  that  structure  affects  IISS  operations.  There  are,  however,  several 
important  points  to  be  made  about  general  data  base  structure  considerations 
which  are  not  tied  directly  to  the  TACOB  data  base  structure: 

1.  The  TACOB  data  base  structure  is  in  some  ways  not  optimum  for 
use  by  U.3.  Army  intelligence  analysts.  Several  examples  will 
clarify  the  nature  of  its  deficiencies: 

a.  Date  and  time  information  is  not  handled  in  TACOB  in 
the  same  way  as  in  other  military  systems.  In  TACOB, 
only  date  information  is  stored.  The  date-time  group 
(DTG)  used  in  most  military  message  traffic  is  not 
employed  by  TACOB.  With  the  DTG  structure,  time 
accuracy  (assuming  valid  input)  is  to  the  nearest 
minute;  with  the  TACOB  structure,  time  accuracy  is 
only  to  the  nearest  day. 

b.  Many  of  the  TACOB  files  are  not  typically  used  by 

U.S.  Army  GOB  analysts  (e.g. ,  air  installation  file; 
runway  file) .  ' 

c.  Even  within  the  TACOB  files  which  are  used  by  GOB 
analysts,  there  are  data  items  which  are  not  employed. 

2.  The  peacetime  orientation  of  ASGOBS  (as  implemented  on  the 
EUCOM  AIDES)  is  manifested  in  two  ways: 

a.  The  focus  on  garrison  and  installation  of  ASGOBS  is 
inappropriate  for  tactical  battlefield  contexts,  where 
units  will  typically  be  in  the  field.  In  this  sense, 
the  TACOB  structure  (focusing  on  units,  rather  than 
fixed  sites)  is  more  germane  to  IISS  operations  than 
ASGOBS . 

b.  EUCOM  AIDES  operation  is  dependent  on  the  availability 
of  hard  wire  data  communication  lines.  Currently,  some 
of  theee  lines  are  leased  from  the  West  German  Bundespost. 

These  communication  lines  will  be  extremely  vulnerable 
during  conflicts. 


Therefore,  using  ASGOBS  implemented  on  EUCOM  AIDES  it  not 
a  viable  option  to  the  use  of  a  true  tactical  analysis  sup* 
port  system. 

3.  Although  the  ARI/Synectics  data  collection  team  did  not  have 
an  opportunity  to  review  the  ASGOBS  data  structures,  know¬ 
ledgeable  usareur  personnel  indicate  that  they  are  quite 
different  from  the  analagous  TACOB  structures.  GOB  ana¬ 
lysts  will  be  using  ASGOBS  (via  EUCOM  AIDES)  during  peace¬ 
time,*  providing  them  with  a  conflicting  set  of  structures 
for  use  during  wartime  is  inadvisable. 

4.  Plans  are  currently  being  made  to  identify  alterations  to 
TACC3  to  maximize  its  compatibility  with  ASGOBS.  It  is 
unlikely,  therefore,  that  TACOB  as  currently  configured 
will  survive  for  long  in  II3S. 

These  conditions  have  a  definite  impact  on  the  nature  of  the  human  factors 
analysis  which  can  be  performed  on  IISS.  On  the  one  hand,  it  is  inappro¬ 
priate  to  spend  too  much  time  discussing  the  implications  of  a  data  base 
structure  which  will  soon  be  superseded.  On  the  other  hand,  it  is  difficult 
to  separate  some  aspects  of  the  data  base  structure  from  the  IlSS-human  inter¬ 
face.  In  other  words,  knowing  something  about  TACOB  is  necessary  to  understand 
the  imperatives  of  IISS  interaction.  This  appendix  addresses,  therefore, 
only  those  aspects  of  TACOB  which  are  (1)  necessary  to  understanding  why  the 
man-machine  interface  of  IISS  evolved  as  it  did  and/or  (2)  likely  to  be 
carried  over  in  any  GOB  implementation. 


TACOB  DATA  BASE  FUNCTIONAL  STRUCTURE 


As  originally  designed,  the  TACOB  data  base  consisted  of  five  separate, 
but  interrelated,  functional  information  clusters.  These  are: 

1.  Ground  Order-of-Battle  File,  which  provides  the  battlefield 
commander  with  information  on  the  enemy  ground  force. 

2.  Air  Order-of-Battle  File,  containing  information  6n  identified 
and  unidentified  enemy  air  units,  including:  location;  strength; 
home  airfields;  etc. 

3.  Biographical  File,  containing  information  on  personnel  associ¬ 
ated  with  enemy  forces  and  units. 

4.  Fire  Support  Management  File,  which  supports  management  of 
fire  missions  on  preplanned  targets. 
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Activities  Processing  and  Collection  Management  and  Diitamlna- 
tion  File,  which  supports  generation  requests  for,  and  dissem¬ 
ination  of,  intelligence  information. 

The  structure  of  each  of  these  "files"  is  displayed  in  Figure  E-2.  Note  that 
many  of  the  separate  information  seta  are  accessible  through  (or  associated 
with)  more  than  one  major  functional  area. 

Interviews  with  IISS  development  personnel  indicate  the  Army  GOB  analysts 
exposed  to  IISS  used  only  the  Ground  Order-of-Battle  and  Personalities  infor- 
'mation  from  TACCB,  While  the  other  sets  of  information  may  be  useful  to 
USARZUP.  analysts  as  their  familiarity  with  the  system  grows,  past  experience 
with  IISS  has  naturally  focused  on  the  kinds  of  information  which  actual  ana¬ 
lysts  use.  Subsequent  discussions  of  TACOB  data  base  structure,  therefore, 
will  concentrate  on  the  Ground  Order-of-Battle  and  Biographical  information 
sets.  Readers  of  this  document  interested  in  other  TACOB  information  sets 
may  consults 

1.  IISS  TACOB  Data  Base  User  Guide,  Document  No.  28503-W100-RU-00, 

TRW  Defense  and  Space  Systems  Group,  15  May  1979. 

2,  IISS  TACOB  Operational  Data  Base,  Document  No.  28503-W101,RU-Q0, 

TRW  Defense  and  Space  Systems  Group,  1  May  1979. 


STRUCTURE  AND  CONTENT  OF  TACOB  DATA  SETS  AND  FILES 


According  to  the  IISS  system  developers,  the  Tactical  Order-of-Battle 
Data  Base  is: 

A  collection  of  information  selectively  chosen  from  the 
European  Command  (EUCOM)  Analyst's  information  Display 
and  Exploitation  System  (AIDES)  Integrated  Data  Base 
and  of  information  that  has  been  loaded  directly  by  an 
intelligence  analyst  as  a  result  of  intelligence  develop¬ 
ment.  The  data  base  consists  of  a  number  of  files  con¬ 
taining  information  about  ground  units,  personalities, 
installations ,  airfields,  air  units,  and  activities ,  and 
missions  assigned  to  friendly  forces  to  accomplish  target 
destruction  and  information  collection.  (IISS  TACOB  Data 
Base  Users  Guide,  p.  1) 

Structure  and  Content  of  the  TACOB  Ground  Order-or-Battle  data  set.  The 
developers  of  the  IISS  (and  the  TACOB  base  structure)  indicate  that: 

The  nucleus  of  the  order-of -battle  files  in  the  Tactical 
Order-of-Battle  data  base  is  the  set  grouped  under  the 


E-5 


srouno  order  of  bathe 
« (film  units 

•  !u*nt'fi«u  .nuj 

•  'JnidAntiflAd  (Wit* 

•  Nrignilimi 
«  InitAllAtlon* 

•  Ground  Unlu  TaPIr 

•  InjtillAtlon*  Toblo 
t  NrionolHIll  T«b1t 

•  Unit  Typ*  IndAX 

•  INSTALLATION  CATEGORY  INDEX 

•  Grid  IndAX 

•  Vo l (nation  TaPIa 

•  Indtx 

t  Country  T a b 1 o 

AIR  ORDER  OF  BATTLE 

•  AIR  UNITS 

•  Idontlflod  Unit* 

•  Unldtntlfltd  Unit* 

•  AIRFIELDS 
«  RUNWAYS 

B  AIR  UNITS  TAILE 
«  AIRFIELD  TABLE 

•  Grid  Ind*x 

•  VAlldAtlon  Tablt 

•  War  IndAX 

A  Unit  Typo  Indox 
A  Country  TaPIa 
a  Initxl lxtlon  CAt  Indox 
a  Wag  IndAx 

BIOGRAPHICAL 
B  PERSONALITIES 
A  PtrtonA 1 1 tl a*  TxblA 
A  Enony  Unit* 

A  VAlldAtlon  TaPIa 

FIRE  MISSION  MANAGEMENT 
B  PRE-PLANNED  TARGETS 
a  Wag  IndAX 
A  Grid  IndAX 
A  InjtAllAtlont 
A  VAlldAtlon  TaPIa 
a  Alrfltldt 
A  AlrflAld  TaPIa 


LSI;’! 

HmH"  ilui 


ACTIVITIES  PROCESSING  AND  COLLECTION 
MANAGEMENT  t  DISSEMINATION 
B  ACTIVITIES 

B  STANOARO  REOUEST  FOR  INFORMATION 
A  VAlldAtlon  TaPIa 


Figure  E-2,  structure  and  Interrelationshioa  in  TAC03  Functional  Information  Clusters 


Ground  order -of -Battle  function.  These  files  provide 
the  commander  and  his  staff  with  information  about  the 
most  immediate  threat  to  the  success  of  a  planned  opera¬ 
tion,  the  opposing  ground  force.  These  files  will  be 
initially  loaded  with  information  obtained  from  the 
EUCOM  AIDES  ASGOBS  and  will  be  maintained  by  the  intelli¬ 
gence  analyst  as  information  is  received  and  processed 
into  acceptable  facts  about  a  particular  unit,  instal¬ 
lation  or  personality  operating  or  located  within  the 
area  of  concern  to  the  commander .  The  principal  files 
provide  location,  strength,  and  training  information  on 
identified  and  unidentified  enemy  ground  units,  biographic 
information  on  individuals  associated  with  those  units, 

'and  descriptive  data  on  installations  within  the  area  of 
interest.  Index  files  facilitate  retrieval  of  this  data 
by  broad  groupings  such  as  UTM  grid  location,  installa¬ 
tion  category,  or  unit  type.  Finally,  various  tables 
are  used  to  validate  or  translate  data  codes  from  user 
format  into  storage  format.  (JISS  TACOB  Data  Base  user 
Guide,  p.  13) 

Principal  files  associated  with  the  Ground  Order-of-Battle  data  set  are 
indicated  in  Table  E-l;  the  file  relationships  within  this  data  set  are 
depicted  in  Figure  E-3.  The  data  elements  contained  in  the  various  Ground 
Order-of-Battle  files  are  listed  in  Tables  E-2  and  E-3.  These  data  elements 
appear  in  the  same  order  in  which  the  whole  record  would  be  printed  by  the 
default  GIM-1I  print  statement.  An  alphabetized  listing  of  data  element 
mnemonics  is  provided  in  Appendix  1. 

Structure  and  content  of  the  TACOB  Ground  Order-of-Battle  data  set, 
the  words  of  the  IISS  developers: 

The  Biographical  files  were  established  to  provide  infor¬ 
mation  to  support  intelligence  development  concerning  per¬ 
sons  who  show  allegiance  to  a  hostile  force.  These  files 
will  be  initially  loaded  with  information  obtained  from 
the  EUCOM  AIDES  ASGOBS  and  will  be  maintained  by  the  intel¬ 
ligence  analyst  as  information  is  received  and  processed 
into  acceptable  facts  about  a  particular  individual.  The 
principal  files  provided  Country  of  Allegiance  and  location, 
grade,  names,  and/or  aliases  to  which  known,  and  unit  of 
assignment  information.  Because  many  persons  may  be  known 
by  the  same  name  and/or  aliases  a  table  is  provided  to  store 
keys  to  all  records  of  individuals  who  are  known  by  a  cer¬ 
tain  name.  (IISS  TACOB  Data  Base  User  Guide,  p.  85) 

Principal  files  associated  with  the  BIOGRAPHICAL  DATA  SET  are  indicated 
in  Table  E-4?  the  file  relationships  within  this  data  set  are  depicted  in 
Figure  E-4.  The  data  elements  contained  in  the  Personality  File  of  the 


Table  E-l 

Ground  Order-of-Battle  Support  Files.  (Reproduced  from 
IISS  TACOB  Data  Base  Users  Guide.  TRW  Defense  and  Space 
Systems  Group/  Document  No.  28503-W100-RV-00/  15  May  1379, 
Table  3. 2. 1.1,  p.  14) 


FILE 

i '  ■ 

FILE  DESCRIPTION 

ENEMY  UNITS 

Contains  information  about  identified  and  unident¬ 
ified  enemy  ground  units  within  a  defined  area  of  j 

of  interest.  Each  unit  record  contains  inform?.-  \ 

tier  on  unit  identification,  location,  strength, 
training,  equipment,  readiness,  and  relationships 
with  other  units. 

PERSONALITIES 

Contains  data  about  personnel  associated  with 

an  enemy  unit  or  force. 

INSTALLATIONS 

1 

"A  source  for  information  concerning  locations 
determined  by  the  DIA  ADPS  center  to  have  poten¬ 
tial  significance  for  intelligence  development  ! 

and  targeting.  Also  assists  the  analyst  in  • 

developing  an  accurate  picture  of  the  battle 
area."  (TACOB  Operational  Data  Base,  p.  16) 

GROUND  UNITS  TABLE 

Contains  all  identifiers  of  a  particular  ground  ' 
unit;  these  identifiers  are  cross-referenced  to 
a  standard  identifier  used  to  access  records  in 
the  ENEMY  UNITS  file.  These  identifiers  are 
also  used  to  translate  unit  synonyms  to  the 
standard  identifier. 

INSTALLATION  FILE 

Contains  all  identifiers  by  which  an  installa¬ 
tion  is  known;  also  contains  cross  references 
to  a  standard  identifier. 

PERSONALITIES  FILE 

Stores  individual  names  along  with  cross  refer¬ 
ences  to  standard  biographical  identifiers. 

UNIT  TYPE  INDEX 

Index  permitting  retrieval  of  unit  records  of  a 
given  type. 

INSTALLATION  CATEGORY' 
INDEX 

Index  permitting  retrieval  of  installation 
records  of  a  given  type. 

GRID  INDEX 

Index  permitting  retrieval  of  records  relating 
to  a  given  geographic  grid. 

VALIDATION  TABLE 

Table  containing  legal  values  for  Ground  Order- 
of-Battle  entries. 

COUNTRY  TABLE 

Table  containing  country  codes  for  all  of  the 
countries  of  the  world. 

UTYPX 


Figure  E-3.  Ground  Order-of-Battle  File  Relationship  for  Validation,  Update, 
Retrieval,  and  Translation. (Reproduced  from  IISS  TACOB  Data  Base  User  Guide. 
TRW  Defense  and  Space  Systems  Group,  Document  No,  28503-W100-R.V-00,  15  May 
1979,  Figure  3.2.1,  page  16). 


Fields  Contained  in  EUNXTS  GOB  File 
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PILE  DESCRIPTION 

PERSONALITIES 

Information  about  persons  who  show  allegiance 
to  a  hostile  force.  The  file  provides  bio¬ 
graphic  Information  to  support  Intelligence 
development  concerning  Individuals,  units, 
or  areas  in  which  Individuals  are  operating. 

PERSONALITIES  TABLE 

Individual  names  are  stored  with  all  the 
standard  Identifiers  associated  with  that 
name. 

ENEMY  UNITS 

Information  about  both  identified  and  uniden¬ 
tified  enemy  ground  units  within  an  area  of 

Interest.  Each  record  contains  basic  identi¬ 
fying  and  location  Information,  as  well  as 
Information  bearing  on  the  unit's  strength, 
training,  equipment,  combat  readiness, 
commanders,  key  staff  members,  and  associa¬ 
tions  with  other  units.  (NOTE:  THE  ENEMY 

UNITS  FILE  IS  PRIMARILY  A  GROUND  ORDER  OF 

BATTLE  FILE,  DESCRIBED  IN  PAGES  THROUGH 

_  OF  THIS  DOCUMENT.)  » 

VALIDATION  TABLE 

Contains  values  that  are  acceptable  to  the 

TACOB  data  base.  (NOTE:  THIS  TABLE  IS 

ACCESSED  BY  ALL  TACOB  FILES.) 

COUNTRY  CODES 

% 

Contains  country  codes  for  all  of  the  coun¬ 
tries  of  the  world.  This  table  verifies 
that  an  input  country  code  value  exists.  The 
Intelligence  analysts  may  dynamically  link  to 
this  table  and  retrieve  the  .full  name  of  the 
country.  (NOTE:  THIS  FILE  IS  ACCESSED  BY 
.  ALL  TACOB  FILES  WHICH  REFER  TO  COUNTRY  CODE 
INFORMATION.) 
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Figure  £-4.  Biographical  Relationship*  for  Creation,  Index,  Retrieval,  and 
Validation.  (Reproduced  from  IISS  TACOB  Data  Base  Uamrs  Guide.  TRW  Defense 
and  Space  Systems  Group,  Document  No.  28503-W100-RV-00,  15  May  1979,  Figure 
3.2.3,  p.  87.) 


BIOGRAPHICAL  DATA  SET  (the  only  file  In  this  data  sat  with  which  usars  intar- 
act  diractly)  ara  listad  in  Tabla  E-5.  Tha  data  alamanta  listad  in  Tabla  E-5 
appear  in  tha  sane  order  in  whcih  tha  whole  raoord  would  be  printed  out  by 
tha  format-default  GIM-IX  language  print  statement.  An  alphabetised  listing 
of  data  element  mnemonics  is  provided  in  Appendix  I. 
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Table  E-5 .  Continued 


APPENDIX  F 


GENERALIZED  INFORMATION  MANAGEMENT 
(GIM)  LANGUAGE  GRAMMAR  AND  SYNTAX 


\ 


GIM  II  COMMAND  LANGUAGE 


VERB 

DESCRIPTION 

ACQUIRE 

Obtains  values  from  the  data  base  under 
control  of  the  Procedure  Oriented  Language 
routines  logic. 

ADO 

A  primary  update  command  used  to  place  all 
values  and  names  into  the  GIM- I I  data  lists 
and  data  list  dictionaries. 

ASSIGN 

Allocates  a  particular  GIM-II  unit 
(physical  device)  as  the  master  terminal. 

BULK-UPDATE 

" 

Updates  a  data  base  with  information  from 
a  file  prepared  outside  of  the  GIM-II 
processor  system. 

CHANGE 

A  primary  update  command  used  to  change 
any  value  and/or  name  in  a  GIM-II  data 
list  and/or  data  list  dictionary.  Com¬ 
bines  the  effects  of  the  DELETE  and  ADD 
commands . 

CHECKPOINT 

A  system  maintenance  verb  that  forces 

GIM-II  system  status  information  to  be 
saved  on  a  disk  for  subsequent  use  in  a 

WARM  start. 
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GIM  II  COMMAND  LANGUAGE 


clear-altpage 


CLEAR- 5YSTRAP 


COMMENT 


COMPILE 


VERB 


DESCRIPTION 


Causes  the  termination  of  alternate  paging 
for  the  current  user.  Used  in  conjunction 
with  the  SET-ALTPAGE  verb  to  analyze  soft¬ 
ware  problems  during  the  development  and 
maintenance  of  the  GIM-II  data  base. 


Used  to  terminate  all  SET-SYSTRAPs  cur¬ 
rently  in  effect.  Primarily  used  to  analyze 
software  problems  during  development  and 
maintenance. 


Any  valid  GIM- II  value  may  be  entered 
after  the  comment  verb. 


Used  to  compile  Procedure  Lists  in  the 
Procedure  Oriented  Language . 


COMPILE-DATA-BASE 


A  data  base  maintenance  verb.  It  acti¬ 
vates  a  dictionary  validation  emd  compila¬ 
tion  of  all  data  list  dictionaries  in  the 
data  base. 


CQMPILE-DICT 


Used  to  validate  a  dictionary  structure 
and  create  a  compiled  dictionary  from  a 
source  dictionary. 


GIM  II  CQMMANO  LANGUAGE 


VERS 

i 

!  DESCRIPTION 

COMPRESS-DICT 

Activates  the  process  by  which  the  com¬ 
piled  dictionary  area  is  compressed. 

COPY 

1  • 

Takes  a  logical  record  in  one  data  list 
and  places  it  in  another  data  list.  The 
record  copied  is  left  unchanged. 

COUNT 

Determines  the  number  of  Item  IDs  in  the 
target  (primary)  data  list  named  in  the 
statement. 

CREATE 

t 

Used  to  create  a  HIT-FILE  using  either  the 
Item  ID  of  the  primary  data  list  or  any 
primary/secondary  attribute  as  the  key 
field  for  the  HIT-FILE. 

DDUMP 

Will  causa  the  physical  and/or  logical  disk 
images  of  the  data  base  records  or  a 
specified  portion  of  the  data  base  to  be 
written  to  tape  or  provide  a  statistical 
analysis  of  a  specified  file  without  a 
dump. 

DDUMP-HDR 

V 

Will  cause  the  header  record  to  be  read 
from  the  back-up  tape. 

F-3 


DELETE-PROCEDURE-LIST 


DISABLE 


DESCRIPTION 


Used  to  create  a  synonym  for  a  data  list 
name  and  optionally  places  the  synonym 
entry  into  a  synonym  dictionary. 


Defines  a  single  segment  or  multisegment 
subset  of  a  segmented  data  list. 


Used  to  remove  any  value  or  name  in  the 
GIM-II  data  list  and  data  list  dictionary. 


Removes  a  data  list  structure  and  all 
references  to  the  data  list  from  the 
data  base.  All  space  previously  occupied 
is  released. 


Removes  a  Procedure  List  and  all  refer¬ 
ences  to  the  data  list  from  the  data  base. 


Disables  a  specified  data  base  from 
processing  any  new  input  statement. 


GIM  II  COMMAND  LANGUAGE 


VERB 

DESCRIPTION 

DISPLAY 

Allows  the  user  to  request  summary  status 
Information  and/or  specific  text  messages 
from  the  user  directed-output  message 
queue . 

DLOAD 

I 

' 

A  utility  function  to  initialize  the  sys¬ 
tem  files  and  dictionaries,  and  load  data. 

DPRINT 

Causes  a  disk  image  of  a  data  base  or 
portions  of  a  data  base  to  be  printed 
as  specified. 

DUMPC 

i 

Causes  a  disk  image  of  the  compile  area 
of  the  data  base  or  portions  of  the  com¬ 
pile  area  to  be  printed  as  specified. 

ENABLE 

f 

Reactivates  a  previously  disabled  data  base 
so  that  new  transactions  may  be  processed 
against  it. 

EXECUTE 

Causes  the  execution  of  a  Procedure  List 
routine  that  has  been  previously  compiled 
via  the  PL-COMPILE  command. 

F-S 


VERB 

DESCRIPTION 

EXTRACT 

Used  to  produce  a  tape  file  that  can  be 
read  by  a  user  applications  program  for 
off-line  report  generation. 

1 

EXTRACTX 

As  EXTRACT  with  the  addition  that  the 
format  of  the  data  is  also  sent  to  the 
terminal. 

EXTRACTC 

Like  EXTRACT  except  the  tape  is  left  open 
and  positioned  at  the  end  of  the  last 
data  record  entry. 

EXTRACTCX 

Like  EXTRACTX  except  the  tape  is  left,  open 
and  positioned  at  the  end  of  the  last 
data  record  entry. 

HISTORY-ANALYSIS 

\ 

INSPECT 

*  , 

Used  to  display  data  size  and/or  page  size 
extended  storage  space  allocations,  or  to 
obtain  a  list  of  GIM-II  units  and  their 
corresponding  hardware  addresses. 

P-6 


if:. 

i-. 


Ciumi  statistical  information  about 
atatamant  tasks  which  ara  activa  in  tha 
various  aiM-U  queues  to  ba  displayed. 


Used  to  create  an  identical  record  in  the 
same  file  with  another  Item  ID. 


Used  to  cause  the  current  extract  tape  to 
be  unloaded  and  the  device  unit  on  which 
it  was  mounted  to  oe  released  to  the  GIM-II 
tape  pool. 


Deletes  the  specified  operator  from  the 
system. 


Calls  a  generalized  report  writer. 


For  data  base  maintenance,  the  user  may 
return  all  or  a  portion  of  the  data  base 
to  a  specified  state  at  a  given  time. 


GIM  II  COMMAND  LANGUAGE 


RESTORE 

t 


VERB 


DESCRIPTION 


Causes  a  rawrita  of  an  antira  data  baia 
or  a  cpacified  portion  tharaof  from  tha 
tapa  which  was  craatad  by  tha  DDUMP  com¬ 
mand. 


1 

I 

I 


RESTRUCTURE- HIT-FILE 


Provides  a  capability  to  alter  the  area 
assigned  to  -a  HIT-FILE. 


ROUTE 


! 


Causes  specified  statements  to  be  routed 
to  the  users'  message  queues  for  eventual 
transmission  to  an  output  device  and/or 
a  pseudo  printer. 


SAVE-DATA-BASE 


Causes  a  copy  of  the  active  data  base  - 
from  zero  to  OSTREC  -  to  be  written  into 
a  save  area.  Used  for  testing. 


SCRATCH 


Used  to  locate  and  delete  messages  from 
the  user ' s  directed  output  queue  without 
printing  them. 


SET-ALTPAGE 


Allows  a  special  page  of  the  GIM- II 
software  to  be  used  in  place  of  the 
normal  page.  Used  during  the  testing  and 
development  phase  of  a  GIM-II  application. 


6IM  II  COMMAND  LANGUAGE 


DESCRIPTION 


SETLINE 


Used  to  change  tha  output  Una  size  that 
la  usually  associated  with  a  particular 
output  davica. 


SET-STATEMENT-NUMBER 


Resets  the  system  sequence  number. 


SET-SYSTPAP 


Allows  a  special  routine  to  be  executed 
before  a  specified  page,  paragraph,  or 
sentence  is  entered  and/or  on  return  from 
a  specified  page,  paragraph,  or  sentence. 


Performs  operations  between  two  attributes 
in  a  primary  data  list. 


TOTAL 


Used  to  sum  the  values  of  a  field. 


SIGNOFF 


Issued  to  terminate  the  user's  access  to 
the  data  base  and  to  the  processing 
session. 


"S* 
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GIM  II 


LANGUAGE 


VERB 

DESCRIPTION 

SIGNON 

Identifies  the  user  to  the  system, 
receives  the  security  keys  necessary 
to  process  the  user's  transactions, 
allows  selection  of  the  user's  data  base, 
and  assigns  any  default  priorities  for 
processing. 

STAF.TGIM 

Activates  and  assigns  a  physical  device 
unit  or  devices  during  the  user's  session. 

STOPGIM 

Deactivates  a  physical  device  unit  or 
devices. 

STRICTIRE-FILE 

• 

Provides  the  foundation  for  a  single- 
segment  data  list. 

\ 

STRUCTURE-PROCEDURE-LIST 

Structures  and  initializes  a  Procedure 

List. 

\ 

STRUCTURE-SEGFILE 

Structures  the  foundation  for  a  seg¬ 
mented  data  list. 

F-12 


0  LANGUAGE 


DESCRIPTION 


Structures  a  dictionary  which  references 
the  same  data  structure  as  an  existing 
dictionary. 


Used  to  terminate  the  current  history  tape 
and  start  a  new  history  tape. 


Provides  the  ability  to  update  a  data 
base  with  bulk  inputs  from  a  magnetic 
tape . 


Used  to  terminate  the  GIM-II  system. 


Used  to  cause  information  about  the 
current  system  users  to  be  displayed. 


A  series  of  modes  which  is  capable  of 
initializing  or  augmenting  a  data  base 
with  card  input. 


$DISTNM/$DZSTSM/$DISTM 
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GIM  II  COMMANO  LANGUAGE 


QUALIFIERS 


DESCRIPTION 


LESS/THAN 

(LT) 


Relational  operator  "less  than". 


EQUAL/TO  OR  LESS/THAN 
(L2) 


Relational  operator  "less  than  or  equal 
to". 


Specifies  criteria  that  will  be  shared 
by  an  adjacent  with-pnrase  or  where- 
phrase . 


WHERE 


Specifies  criteria. 


specifies  criteria. 


NEAREST 


In  closest  proximity. 


61 M  II  COMMAND  LANGUAGE 


QUALIFIERS 


GIM  II  COMMAND  LANGUAGE 

I  DESCRIPTION 


when  appended  to  any  data  list  name  may 
be  considered  as  a  processing  qualifier. 
Restricts  the  action  of  the  verb  to  the 
dictionary  for  the  data  list  as  opposed 
to  the  data  list  where  the  values  are 
stored. 


Address  qualifiers.  Once  a  data  list  is 
properly  addressed,  or  limited,  by  these 
qualifiers,  all  other  data  lists  on  the 
data  base  are  excluded  from  consideration. 


Addition. 


Arithmetic  subtraction. 


Arithmetic  multiplication. 


Arithmetic  division 


6IM  II  COMMAND  LANGUAGE 

QUALIFIERS  | _  DESCRIPTION 


EVERY  Causa  the  attribute  or  expression  bain? 

modified. to  be  evaluated  across  all  of 
the  other  attribute's  values. 


SDATEl 


System  date  in  YYMMDD  format. 


SDATEG 


5DATEDD 


GIM-II  format  date  in  integer  number. 


5DATEMM 


Month. 


$DATEYY 


Year. 


5UNAME1 


Organization  nama  of  user  "signed-on 


5UNAME2 


Name  of  usar  executing  the  statement 


SUSEQI 


Sequence  number  of  input  statement. 


\ 


SUSEQP 


Sequence  number  of  input  statement 
within  a  procedure. 


$USTIME 


Transaction  time  logged  for  input 
statement. 


User  input  device  number. 


Tally  containing  an  error  message  number. 


Start  time  of  session  in  hours  to  four 
places. 


$DBNAME 


Date  base  name;  user  ISGNON  statement. 


DIM  II  COMMAND  LANGUAGE 


CONNECTIVES 


AND 


>R 


NOT 


DESCRIPTION 


The  logical  connect iva  having  the  following 

truth  table »  AMD  _ 

T  t  T 
T  F  F 
FTP 
F  F  F 


The  logical  connective  having  the  following 

truth  table:.  OR  _ 

T  T  T 
TFT 
F  T  T 
F  F  F 


The  logical  connective  having  the  following 
truth  table: 


IF... THEN... ELSE 


A  series  of  connectives  usable  only  in 
the  context  of  the  update  edits. 


Uear  input  device  number. 


Tally  containing  an  arror  massage  number. 


Start  time  of  session  in  hours  to  four 
places. 


Data  base  name;  user  ISGNON  statement. 


\ 


(iiM  II  COMMANO  LANGUAGE 


CONNECTIVES 

DESCRIPTION 

AND 

The  logical  connect 
truth  tablet  AND 

T  T 

T  F 

P  T 

P  P 

1 

ive  hawing  the  following 

"t 

F 

P 

F 

OR 

The  logical  connect 
truth  tablet.  OR 

T  T  j 
T  F 

F  T  ] 
P  F 

ive  having  the  following 

"t 

t 

T 

F 

NOT 

The  logical  connect 
truth  table: 

A _ 

T 

F 

ive  having  the  following 

NOT  A 

F 

T 

A  series  of  connectives  usable  only  in 
the  context  of  the  update  edits. 


APPENDIX  6 

SNITCHES  USED  IN  IISS  MMI  FORMS 


DESCRIPTION  OF  SWITCH  FUNCTION 


Routes  t  uur  Massage  to  elV users  logged  on  it  *  specific  tit*. 


/  • 

Output  to  »n  intended  to  mi  existing  flit. 


Spool flti  blccx  ilii  tor  tape  or  dish  flit. 


Input  flit  to  bt  dtltttd  it  c'.om. 


Flit  bit  FORTUN  carriage  control. 


Flit  Specification  Indication. 


Otto  trtnttl ttlan  through  high-speed  lint. 


Libtl  type  for  magnetic  tipt. 


Sptclfltt  lift  only  device. 


Sperries  uttr  terminal. 


Soft  dtvlct  Is  not  to  bt  logged  on. 


Operator  It  to  rtctlvt  atsttgt. 


Priority  Indicator. 


Rreaeble  for  toft  dtvlct. 


httaln  message  for  user  not  logged  on. 


Record  format  for  blocked  filet. 


Sptclfltt  rt-opening  of  continuation  flips. 


Specifies  record  size. 


Sptclfltt  site  naae. 


Output  to  be  spooled  to  directed  output. 


Existing  flit  version  to  bt  superseded. 


Override  lint  slit  for  flit. 


Foreign  tape  file'. 


Magnetic  tape  file. 


Update  existing  version  of  flit. 


Input  till  coat  fro*  the  user  terminal . 


Votoat  label  for  Magnetic  tire. 


START  DEVICE  * 

USER  MESSAGE  ? 
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APPENDIX  H 


RECORD  ELEMENT  CODES  VSED  iN  IIS'S 


\-.  I: » 'i 


»  >  v*^tl  K«  U«  « 


•r;'-  ‘"'•^•■'y 


MNEMONIC 

ABBREVIATION 

ACCNO 

.  ACES-NO 

ACES-NO 

ACCUR 

EVA-ACCUR 

ACFTF 

ACFT-FCTN 

ACKIN 

ACK-IND 

ACMSG 

MSG 

MSG 

MSG  '  '  *  . 

ACRmG 

ACFT-RNG 

ac  r  r 

ACT-IDENT 

ACT!  D 

ACT- 1  DENT- FID 

AT  T'V/DT 

Awi  i.  f  ft  1 

GEO-COORD-SEC 

GEO-COORD-SEC 

ACTXT 

ACT-TEXT 

ACTYP 

ACFT-TYPE  * 

AGATE 

OATE-PERS-PRES 

AEOBF 

EOB-FIDA 

EOB-FIDA 

AFDID 

AFLD-ID 

AFDIDPT 

GEO-COORD-SEC 

GEO-COORD-SEC 

AFTBL 

AFLD-ID 

ALIGH 

RWY-HDG 

ALIGS 

RWY-ALIGN 

ALTNM 

UNIT-ALT-NAME 

AMSLS 

ASSOC-MSL-TYPE 

ANALC 

ANAL- I DENT 

ANAL- 1  DENT 

ANGSC 

SEC-ANG 

APLAT 

ASSOC-PLATF-TYPE 

APRTY. 

PRY 

PRY 

ARDEF 

AD-DIST 

AROTG 

DTG-ARMY 

ARFLD 

NAM-ARFLD 

ARFLDF 

AFLD-ID 

ARFLDT 

AFLDF-ID 

ASCAP 

RWY-CAP 

ASCAS 

RWY-CAPACTY-STAT 

ASGRD 

GRD-ARMD-SVC 

ATIME 

T-ORIG-UPD 

ATYPE 

ACT-TYPE  . 

AUNIT 

ATT- UNITS 

AUNTF 

EUNIT-AIR  • 

AUTBL 

EUNIT-AIR 

AWPNS 

ASSOC-WPN-SYS 

BDMGA 

BAT- DMG-ASSESS- FLAG 

BEAMW 

BM-WD 

RENUM 

BSC-ENCL-NO 

BSC-ENCL-NO 

BSC-ENCL-NO 

BSC-ENCL-NO 

MNEMONIC 

ABBREVIATION 

BLOCK 

MSG-BLK-COUNT 

BSOLD 

BASE-LD 

CALEG 

CNTRY-CODE 

CATCD 

FUNCTCLASS 

FUNCTCLASS 

CONTY 

CNTRY-CODE 

CDIGR 

COLL-TRIG 

CL  OAT 

CUR-LOC-DTD 

CM3RB 

RDMS-RTG 

CM;' OP 

CMNDR-NAME 

CMS.TO 

COL-MSN-NO 

COL-MSN-NO 

CNTRY 

CNTRY-WORLD 

COLOC 

CNTRY-CODE 

CPNAM 

COLL-PROJ-NAME 

CROAT 

DATE 

CPrtKG 

CGNT-RLSE-MK 

CONT-RLSE-MK 

CR  i  *IM 

CURR-UNIT-NAME 

CSDAT 

DATE 

CTPIG 

COL -TRIG 

CUNIT 

CONT-UNIT 

CYCIR 

CY-ILLUM-RT 

DAREA 

MIL-DEF-AREA-TMP-LOC 

MIL-DEF-AREA-TMP-LOC 

DATE 

DATE 

DECAT 

DECLAS-CAT 

DECLAS-CA7 

DGDCM 

DWNGRADE 

DOCCL 

DOC- CLASS 

DRCRM 

OOC-CONT-RLSE-MK 

DOC-CONT-RLSE-MK 

DRDGN 

DOC-CLASS 

DRDTG 

DRAFTDT 

ORGDS 

60S 

GDS 

DRG 

DTG-DEST 

DSDTG 

ODTG-DEST 

D5PTY 

DEST-PRY 

DUN  IT 

DESIG-UNIT 

EA I  ID 

EUC-AID-ID 

EANAL 

EXPLI-ANAL-FCTN/NAME 
EX  PL I *  ANAL -fCTN/NAME 

FBSEQ 

EOB-SEQ-NR 

EOB-SEQ-NR  ' 

ECHLV 

GD-UNITECHL 

Ef-TBL 

EPL-FMT-TSL-TD 

EFJNC 

EQPT-FCNT 

ELORI 

ELP-ORIENT 

ENOOt 

EXPLODE 

EXP-NODE 

EXP-NODE 

H-2 


MNEMONIC 


ABBREVIATION 


EOBF 

EOBIO 

EOTGT 

EPLT8L 

EQATH 

EQPOH 

EQTYPE 

EP.ESP 


ESCAN 

ESYSF 

ETFLG 


EUNITS 

EUSER 

EXADR 

EXCAT 

EXRNM 

FHDAT 

FHSTR 

FHTOT 

FLAGS 

FLGWD 

FMODE 

FNAME 

FRINT 

FUDEF 

GOSCH 

GEOLO 

GLOCN 

GNIOX 

GRADE 

GRIDX 

GUIDE 

GUTBL 

HEAD 

HGEL 

HGEOL 

HLORI 

HPRFR 

HSDTG 

HSMAA 


EOB-FID 

EOB-FID 

EOB-ID 

EOB-ID 

TGT-DMG-ASSESS 

EPL-TBL-ID 

EQPT-ENT-AUTH 

EQPT-ENT-ON-HAND 

EQUIP-CD 

EXP-ADRS-RESP-CODE 

EXP-ADRS-RESP-CODE 

EXP-ADRS-RESP-CODE 

ELEC-SCNR-P 

ELINT-SYSF-ID 

EXPL-PRCS-FLAG 

EXPL-PRCS-FLAG 

EXPL-PRCS-FLAG 

EUNIT 

EQPT-USER  • 

EXPLI-ADRS 

XGDS-CAT 

XGDS-CAT 

EXER-NAME 

FX-STR-DATE 

FOXH-STR-TOT 

FOXH-STR-TOT 

STAT- FLAGS 

FLAGWORO 

XMSN-FMT-MOD 

PERSNF 

PERSNF 

FRG-RT-INT 

FUNC-DEF 

CDS 

GDS 

GEO-COORD-SEC 

GEO-COORD-SEC 

GEO-COORD-CONV 

GEO-COORD- CONV 

RWY-GRADE 

GRID-1 K-LOC 

GRID-1 K-LOC 

MSL-GUID-SYS 

EUNIT-GRD 

RWY-HDG 

GEO-COORD-SEC 

GEO-COORD-SEC 

GEO-COORD-SEC 

HIST-ELP-ORIENT 

H-PRF 

DTG-HIST 

HIST-SEMI-MAJ-AXIS 


MNEMONIC 

ABBREVIATION 

HSMIA 

HI ST-SEMI -MIN-AXIS 
HIST-UTM 

HIST-UTM 

IAIRF 

AR-UNT-ID 

IAIRU 

AR-UNT-ID 

ICATD 

INST-CST- INDX 
INST-CAT-INDX 

ICATX 

INST-CAT-INDX 

INST-CAT-INDX 

IEOBF 

EOB-FIDI 

EOB-FIDI 

IN  CAT 

INST-CAT-INDX 

INST-CAT-INDX 

IN  DAT 

DATE 

INNUM 

INSTG-IDENT-SERNO 

INSTG-IDEMT-SERNO 

INSTG-IDENT-SERNO 

INSID 

INST- ID 

I  NS I  DPT 

GEO-COORD-SEC 

INSTF 

INSTF- ID 

I  UN  IT 

ENEMY-GROUND-UNIT 

IUNITPT 

GEO-COORD-SEC 

GEO-COORD-SEC 

IUNITS 

EU-UNT-ID 

JETBR 

RWY-JET-BAR 

JLDAY 

DA-OF-YR 

KSMEM 

KEY-STF-MEM-NAM 

LAHME 

LAT-HEMSPHR 

LATIC 

LAT-SEC-ANG 

LATTD 

LAT-DEG 

LATTM 

LAT-MIN-ANG 

LCNTY 

CNTRY-CODE 

LNAME 

LST-NM-PRSN 

LNGTH 

RWY- LNGTH 

LNGTS 

RWY- LNGTH- STAT 

LOCAT 

LOCATION 

LOHEM 

LONGE-HEMSPHR 

LONGD 

LONGE-DEG 

LONGM 

LONGE-MIN-ANG 

LONGS 

LONG-SEC-ANG 

LPRFR 

L-PRF 

LTIOV 

MSG-ORIG 

MIDEF 

MOD-TYPE-DEF 

Ml  DEL 

MOD-TYP-DEF 

M2DEF 

MOD-DESC-DEF 

MAXMA 

MAX-MSL-RNG 

MAX-MSL-RNG 

MAXMN 

UPR-RF-RNG 

MASMR 

MAX-MSL-RNG 

MAXPW 

PW-RT3G 

MAXRF 

UPR-RF-RNG 

UPR-RF-RNG 

MAXRT 

MAX-RCTN-T 

MAX-RCTN-T 

H-4 


MNEMONIC 


ABBREVIATION 


MAXSP 

MAXSU 

MAXTD 

MCOOE 

MGTXT 

MI  DEN 
MINMA 
MINMN 
MINMR 
MIN  PM 
MINRF 

MINRT 

MINSU 

MINTD 

MINTM 

MNAME 

MOBIL 

MOBRD 

MOBRI 

MOBRP 

MODAY 

MODEF 

MODLN 

MONTH 

MORIG 

MOSET 

MSDEF 

MSGLN 

MSLF 

MSLLD 

MSNNO 

MSNNR 

MSPTY 

NARTV 

NCNTY 

NODAY 

NODE 

G8STH 

OBSTN 

OBSTR 

OBSTS 

OBTYP 

OHDAT 

ONAME 

ONTUM 


ACFT-VLCTY-NAUT-MI-HR 

MAX-SU-T 

MAX-TD-T 

MODE-CODE 

msg-txt 

MSG-TXT 

MSG- I DENT 

IWR-RF-RNG 

LWR-RF-RNG 

MIN-MSL-RNG 

PW-RNG 

LWR-RF-RNG 

lwr-rf-rng 

min-rctn-t 

MIN-RCTN-T 

MIN-SU-T 

MIN-TD-T 

MIN-TIME 

MDL-NM-PRSN 

MBL 

DIRT-MBL-RT 

IMPROV-MBL-RT 

PAVED-MBL-RT 

DA 

MOD-DEF 

MODLTN 

MONTH 

MONTH 

MESSAGE-ORIG 

MESSAGE-ORIG 

MODE-SET 

MOSET-DEF 

MSG-LINE-NR 

MSLF- ID 

BSC-MSL-LOAD 

MSN-NUM 

MSN-NUM 

MSN-NUM 

PRY 

PRY 

MSG-TXT 

CNTRY-CODE 

DAYS-OF-UNIT-TNG 

NODE 

NODE  ' 

RWY-OBSTN-HEIGHT 

CONT-RWY-OBSTN 

RWY-CONT-OBSTN-STAT 

ORD-BTL-TYP 

ORO-BTL-TYP 

DT-NO-ON-HD 

OTHR-NM-PRSN 

ORIG- UNIT-UTM 

ORIG-UNIT-UTM 


H-5 


MNEMONIC 


ABBREVIATION 


OPMOD 

OPRNM 

ORGEO 

ORGIN 

ORIGN 

ORUIC 

ORUTM 

PANAL 

PDAT1 

PCAT2 

PDAT2 

PDAT4 

P0AT5 

PDRNG 

PERSNF 

PFUNC 

PGSZE 

PINNO 

PLATF 
PLATT 
PL  DAT 
PLM08 
PNAME 
PNODE 


PNTBL 


POBOX 

PODEF 

POLAR 

PPOAT 

PPRIDPT 

PPTGT 

PPTID 

PPTIDPT 

PRADR 

PRAFD 

PROOB 

PRESP 


PRFRG 

PRIND 


OP-MOD 

OPN-NAME 

GEO-COORD-SEC 

MSG-ORIG 

RCD-ORIG 

ORIGUIC 

ORIG-UNIT-UTM 

PF-ANAL-FCTN/NAME 

PF-ANAL-FCTN/NAME 

DATE 

DATE 

DATE 

DATE 

DATE 

PD-RNG 

PD-RNG 

PERS-ID 

PERS-FUNC  > 

PLS-GP-SIZE 

PINNO 

PINNO 

PLATF- 1  DENT 

PLATF-TYPE 

PREV-LOC-DTD 

PLATF-MBL 

PERS-NAMW 

PROF- NODE 

PROF-NODE 

PROF=NODE 

OTHR-NM-PRSN 

OTHR-NM-PRSN 

OTHR-NM-PRSN 

PO-BOX 

PLZN-DEF 

PLZN 

DATE-PERS-PRES 

GEO-COORD-SEC 

GEO-COORD-SEC 

PRE-PLND-TGTS-IDENT 

PRE-PLND-TGTS-IDENT 

PRE-PLND-TGTS-IDENT 

GEO-COORD- SEC 

GEO-COORD-SEC 

PF-ADRS 

PF-ADR^ 

NAM-ARFLD-PREV  ' 

NAM-ARFLD-PREV 

DOB 

PROF-ADRS-RESP-CODE 

PRQE*ADRS*'RESP-CODE 

PROF-ADRS-RESP-CODE 

PRF-RNG 

PRGM-IDN 

PRGM-IND 

PRGM-IND 


H-6 


t 


MNEMONIC 

ABBREVIATION 

PROCX 

PRCS- INDEX 

PRSAT 

PERS-AUTH 

PRTOT 

PERS-AUTH-TOT 

PRUTM 

PREV-UTM 

PSNID 

PERS-ID 

PSTAT 

PLATF-STAT 

PTFLG 

PF-PRCS-FLAG 

PF-PRCS-FLAG 

PF-PRCS-FLAG 

PTYPE 

PLATF-TYPE 

PUN  IT 

PP.NT-UNTT 

PUTM1 

GEO-COORD-SEC 

PUTT-12 

GEO-COORD-SEC 

PUTM3 

GEO-COORD-SEC 

PUTM4 

GEO-COORD- SEC 

PUTM5 

GEO-COORD-SEC 

PWRNG 

PW-RNG 

RANGE 

MSL-RNG 

MSL-RNG 

RORAL 

RDR-ALT 

RORCO 

RDR-CGV 

RORNG 

RDR-RNG 

REACT 

RCTN-T 

RECLS 

SECLAS-GP-REC 

SECLAS-GP-REC 

REDAT 

DATE 

RFRNG 

RF-RNG 

RI  ID 

RIIF-IDENT-FLD 

RIIDPT 

GEO-COORD-SEC 

GEO-COORD-SEC 

RI  I F 

RI IF- 1  DENT 

RIIID 

RIIF-IDENT-FLD 

RMARK 

PUBL-RMARK 

RMCLS 

SECLAS-GP-RMK 

RMKEY 

PUB-RMK-KEY 

RMKLN 

RMK-LINE-NR 

RMK-LINE-RN 

RMTXT 

PUBL-RMK-TXT 

PU8L-RMK-TXT 

RPDTG 

DTG-RPTING 

RQDAT 

DATc-INF-REQ 

RQDTG 

DTG-RPTING 

RQPTY 

RQT-PRY. 

RQT-PRY 

RRDAT 

DATE  , 

RWY 

RWY- 1  DENT 

RWY- 1  DENT 

RWYDSG 

RWY-DSG 

RWY-DSG 

RWYF 

RWY- 1  DENT 

RWYFID 

ARFLDF-RWY 

RWYID 

RWY- 1  DENT 

H-7 


jtaaav  • 


SCANP 

SCANT 

SCLSG 

SCOMC 

SCOME 

SCOMP 

SDAT1 

S0AT2 

30AT3 

I'lVITI 

wun  i  t 


SECTN 


SEDEF 

SEDSC 

SERNO 


SFLGW 

SIGUS 

SITNO 

SMAAX 

SMIAX 

SMTYP 

SNDEF 

SORCE 

SPDEF 

SPEED 

PSHDl 

SPHER 

SPHRO 

SQNNO 

SRCLO 


SRELI 

SSTYP 

STAOD 

STCAT 

STDEF 

STDTG 

STIME 

SUB  ID 

SUNIT 

SUPTP 

SUPTS 

SURFC 

SURFS 

SUTIK 

SYEOP 

SYMOB 

TDESC 

TDNTP 

TDNTS 

TDTIM 


ABBREVIATION 

SCNR-P 

SCNR-TYPE 

SECLAS-GP 

SYS-CMMPNT-EQUIP 

SYS-CMPNT-COMM 

SYS-CMPNT 

DATE 

DATE 

DATE 

DATE 

SECLAS 

SECLAS 

SECTIONING 

SECTIONING 

SED-CHAR-DEF 

SED 

MSG-SER-NR 

msg-ser-nr 

FLGWSEC 
SIG-USE 
SITE- NO 
SFMI-MAJ-AXIS 
SEMI-MIN-AXIS 
SURF-MATL-TYPE 
SED- FCHAR-DEF 
SOURCE 

SED-PCHAR-DEF 

MSL-SP 

CODEWORD 

SPHER 

SPHER 

SEQ-NO 

ACT-SOURCE-UTM 

ACT-SOURCE-UTM 

EVAL  OF  RELIABILITY 

SYS-SITE 

ST-ARDS 

STR-CAT 

SCAN-TYP-DEF 

DTG-SITING 

STMT-T-UPD 

SUBJ-IDENT 

SUB-UNITS 

PLATF-SU-RNG 

SYS-SU-RNG 

SURF-MATL-TYPE 

RWY-SURFC-STAT 

SET-UP-T-RNG 

EQPT-REF-NO 

SYS-MBL 

TGT-DES 

PLATF-TR-DN-RNG 

SYS-TR-DN-RNG 

TR-DN-T-RNG 


H-8 


t 

f 


MNEMONIC 

ABBREVIATION 

TGRNO 

UNIT-TGT-NO 

TITLE 

RPTREQ 

RPTREQ 

TNGSP 

TNG-SPCL-MIL 

TNRES 

TWN-OF-RES 

TRDAT 

TNG- DATE 

TRHEM 

TERR-HEMSPHR 

TRJAL 

MSL-TRAJ-ALT 

MSL-TRAJ-ALT 

TRLOC 

TNG-LOC 

TRPLD 

TROOP-OD 

TRTYP 

TRN-TYPE-KEY 

TZONE 

T-ZONE 

UAIRF 

UNIDENT-AUNIT 

UAIRU 

UNIDENT-AUNIT 

UDATE 

UPD-DATE 

UGRID 

GRID-IK-LOC 

UIC 

UIC 

ULOCN 

UTM-LOC 

URDLE 

SYC-SUPRT 

SYC-SUPRT 

USCAN 

UPR-SCRN-P 

USDEF 

USER-DEF 

UTMLO 

UTM-LOC 

UTM-LOC 

UTYPE 

UNIT-TYPE 

UNIT-TYPE 

UTYPES 

UNIT-ORG-TYPE-SPEC 

UNIT-ORG-TYPE-SPEC 

UUNIT 

UNIDENT-GUNIT 

UUNITPT 

GEO-COORD-SEC 

GEO-COORD-SEC 

UUNITS 

UNIDENT-ENEMY-U 

WAG 

WAG 

WAGX 

WAX-INDEX 

WAG- INDEX 

WAREA 

WAC 

WAC 

WAC 

WAC 

WARHD 

MSL-WHD 

WIDTH 

RWY-WIDTH 

WIDTH 

RWY- WIDTH- Sf AT 

WTCAP 

RQY-WT-CAP 

YEAR 

CONVS-COMPL-YR  ' 

H-9 


LOGON  —  ENTER  ORGANIZATION  AND  USER  NAME 
LOGON  —  ENTER  PASSWORD 
LOGON  —  INVALID  FORMAT 

LOGON  --  NO  SECURITY  HEADER  FOR  USER 
LOGON  —  LOGON  COMPLETE 

LOGON  --  INVALID  ORGANIZATION,  USER,  OR  PASSWORD 
LOGON  -  USER  AND  DEVICE  SECURITY  LEVEL  MISMATCH  LOWER  USED 
,  LONON  —  USER  IS  LOCKED  OUT  OF  SYSTEM 
LOGON  —  MAXIMUM  LOGON  ATTEMPTS  EXCEEDED 

S10117  'M  -10A  LOGGED  ON  %20%Q  AT  X2A.X4A  HOURS  ON  S2A/X2A/X2A 

SI  1 7  '.'6 A  10  LOGGED  OFF  X2AX0  AT  X2A.S4A  HOURS  ON  X2A/X2A/X2A 

LOGOFF  --  LOGOFF  COMPLETE 

LOGOFF  —  THIS  DEVICE  IS  NOW  HALTED 

LOGOFF  -  INVALID  PARAMETER 

INGIM  —  COULD  NOT  FIND  X8A  DATA  BASE 

INGIM  —  DATA  BASE  NAME  SPECIFIED  EXCEEDS  8  CHAR 

INGIM  —  MO  DATA  BASE  NAME  SPECIFIED 

INGIM  --  INVALID  SWITCH  (/SI:  IS  THE  ONLY  VALID  SWITCH) 

INGIM  —  INVALID  INPUT  FORMAT  FOR  GIM  OPTION 
"SA  COMMUNICATIONS  ARE  UNAVAILABLE  AT  THIS  TIME 
MENU  --  OPTION  X8A  UNAVAILABLE  TO  THIS  DEVICE 
MENU  —  OPTION  -;8A  NOT  FOUND  IN  USERS  MENU  FILE 
MENU  —  OPTION  :J6A  TOO  LONG  (MAXIMUM  OF  6  CHARACTERS) 

INGIM  —  OPTION  TERMINATED 

INGIM  —  CONFLICT  IN  SPECIFICATION  OF  SITE 

INGIM  —  DATA  BASE  NAME  CONFLICT 

MTHOLD  —  ILLEGAL  CHARACTERS  FOUND  IN  INPUT  STREAM 

MTHOLD  —  WORD  TOO  LONG,  INVALID  EXECUTIVE  COMMAND 

MTHOLD  --  DELIMITERS  ARE  NOT  8ALANCED 

HELP  -  HELP  OPTION  (SHORT/LONG)  MISSING  LONG  DEFAULTED 

OPTION  DESCRIPTION 

OPTION 

IBOB  -  UNCORRECTABLE  I/O  ERROR  HAS  OCCURED  ON  UNIT  X2AX0 

IBOB  -  STOPGIM  INVOKED  ON  UNIT  X2AX0 

INTRR  -  INVALID  INTERRUPT  REQUEST 

INTRR  -  STATEMENT  WAITING  TO  BE  INITIATED 

INTRR  —  STATEMENT  IN  PROGRESS  %VA,XVA,XVA,XVA 

INTRR  —  STATEMENT  WAITING  FOR  EXCLUSIVE  USE  OF  RESOURCE 

INTRR  «  STATEMENT  WAITING  FOR  DATA  BASE  MOUNT 

INTRR  —  STATEMENT  WAITING  FOR  TAPE  TO  BE  MOUNTED 

INTRR  -  STATEMENT  IN  PROGRESS 

INTRR  —  STATEMENT  IN  PROGRESS 

INTRR  —  PAGE  =  %D,  LPP  =  %D,  SKIP  »  XD,  WAIT  «  XD 

INTRR  —  END-QF-PAGE  WAlt  COONT  SET 

INTRR  —  INVALID  FORMAT  QN  INTERRUPT  REQUEST 

INTRR  —  DEVICE  DOES  NOT  SUPPORT  PAGING 

INTRR  —  LINES  PER  PAGE  SET  TO  XD 

INTRR  —  NEGATIVE  LINES  PER  PAGE  -  NOT  SET 

INTRR  —  PAGING  DISABLED 

INTRR  —  OUTPUT  WILL  NOT  BE  SCRATCHED 

INTASK  —  CANNOT  OBTAIN  EXCLUSIVE  USE  OF  DATA  BASE 

INTASK  —  DIRECTIVE  ERROR 

MENU  -  DATA  BASE  NOT  DEFINED  TO  SYSTEM 


l-l 


HA 3  NOT  BEEN  INITIATED 
HAS  BEEN  CANCELLED 
HAS  BEEN  ABNORMALLY  TERMINATED 
HAS  BEEN  .TERMINATED  FOR  REASONS  OF  SECURITY 


STRTDV 

STRTDV 

STRTDV 

STRTDV. 

STRTDV 

STRTDV 

C 

-,;r: 

"“DTI1' 

-  .  li  i  U  I 

STRTDV 

STRTDV 

STRTDV 


7  SYNTAX  ERROR 
-..SAD  SWITCH  OR  SWITCH  VALUE  '  . 

•  DEVICE  NOT  SUPPORTED  ’ 

-  NO  INPUT  CAPABILITY 

-  *  LO’  CANNUT.BE  USED  WITH  INPUT 

-  TASK  IMAGE  LOAD  FAILURE 

-  DEVICE  NOT  DEFINED  IN  MENU , 

NOW  'THE  MASTER  TERMINAL  , 

-  MT  MUST  BE  INTERACTIVE 

-  .LOGON  FOR  SOFT  DEVICE 

-  DEVICE  ALREADY  ASSIGNED  " 

-  DEVICE  UNAVAILABLE 


STRTDB  —  INVALID  QUEUE,  NUMBER,  ."  '  -  TV  ■■ 

6A  "MCA  ON  UNIT  DD  FAILED  SOFT  DEVICE  SECURITY 
TERM  —  SYSTEM  TERMINATION  IN  PROGRESS 
USER  ORG  DEV  UNIT  -  DATABASE  PROGRAM 

I1CA  V6A  TP  A  DO  DO.  ",3'A  '  %2P. .  H2QA 

USER  ORG  DEV  UNIT  . 

'll CA  D6A  S2ADO  "ID. 

STOPDV  —  INVALID  UNIT  NUMBER 
STOPDV  —  DEVICE  ISO-  NOT  ALLOCATED 


STOPDV  DEVICE  %D.  STOPPED  ■  ■  v  '  V 

INTRR  —  MENU  OPTION  S2R  IN  PROGRESS.  ,  .  ■ 

COPY  --  %t)  RECORDS  PROCESSED  , 

COPY  --  ERROR  ON 'INPUT  . 

COPY  —  ERROR  ON  OUTPUT 

COPY  —  INVALID  SWITCH  OR  FORMAT  . 

COPY  v-  GETIB  BUFFER. OVERFLOW 

COPY  —  UNEXPECTED  END  OF  INPUT 

COPY,  —  OPEN  ERROR  ON  OUTPUT  DEVICE 

COPY  —  CPEN  ERROR  ON  INPUT  FILE  .  . 

MSGTC—  DIRECTED  OUTPUT  SEND/DATA  ERROR 

VRCO  --  INVALID  P.ECE  I  VE/DATA  ERROR 

******WARNING;  %8A  COMPILE  AREA  THRESHOLD  %D%%  ****** 


******WARN!NG:  %8A  STRUCTURE- FILE  THRESHOLD  %0%%  ****** 


UNABLE  TO  OBTAIN  EXCLUSIVE  USE.  CALL  SYSTEMS 
SAD  DATA  BASE  COUNTS.  CALL  SYSTEMS 
S6A-S10A  SIGNOFF  FORCED  DUE  TO  EXCESSIVE  PSV. 
26A-S10A  HAS.  HAD  %D  PSV  SINCE  SIGNON. 

SYSTEM  TERMINATION  IN  PROGRESS 

DATA  BASE  SDA  HAS  BEEN  DISABLED 

ERROR  IN  MENU  FILE.  SEE  DATA  BASE  MANAGER 

VALUE  ON  SWITCH  WHICH  REQUIRES  NO  VALUE 

INVALID  SITE  SPECIFICATION 

REQUIRE  ADDRESSEE  NOT  SPECIFIED 

INVALID  SWITCH  OR  SWKCh  VALUE 

INPUT  FILE  HEAD  ERROR 

WRITE  ERROR  ON  MSNTOS  FILE 

ENTER  DATANFT  ID 
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INVALID  SYNTAX 
COMPLETED 

UNABLE  TO  OPEN  MSNTOS  FILE 

ERROR  ON  CLOSE  OR  ROUTE  OF  MSNTOS  FILE 

ERROR  ON  OPEN  OF  INPUT  FILE 

INVALID  USER  NAME.  TOO  LONG 

/FI  CANNOT  BE  USER  WITH  MULTIPLE  NAMES  OR  SWITCHES 

OPENX  — •  REQUEST  CANCELLED 

OPENX  —  TAPE  DRIVE  NOT  AVAILABLE 

OPENX  -  INVALID  DEVICE  NAME 

OPENX—  INVALID  UIC 

OPENX  --  FILENAME  EXCEEDED  9  CHARACTERS 


v>  4  -  .  I  A  ‘ 
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'ERS 
CHARACT 


ERS 


OPENX'.' 
.  OPENX 
..OPENX 
OPENX 
OPENX 


•ENSIGN  EXCEEDED  3  CHA: 

OPENX  ...  -FILE  VERSION  NUMBER  EXCEEDED 
CERNX  --  NO  FILENAME  ON  INPUT  ‘ 

OPENX  -NO ‘VOLUME  ID  ON  INPUT 
OPENX  -  MISSING  (  )  IN  UIC 
GDENX  -MISSING  (  )  IN  UIC 
.OPENX  -  ILLEGAL  CHARACTER  (  MIA  )  IN  UIC 

ILLEGAL  CHARACTER  (  MIA  )  IN  FILENAME 
ILLEGAL  CHARACTER  (  MIA  )  IN  FILE  EXTENSION 
ILLEGAL  CHARACTER  (  MIA  )  IN  FILE  VERSION  NUMBER 
INVALID  SWITCH  (  MVA  ) 

Ml  R  RUN  FAILURE 

OPENX  —  SEND  DATA  FILAURE  TO  MIR  - 

OPENX  —  RE-OPEN  SEND  DATA  FAILURE  TO  Ml R 
REPLY  N  IF  NO  DRIVE,  D  TO  DELAY,  OR  DRIVE  UNIT  * 

REPLY  N  IF  NO  DRIVE,  D  TO  OELAY,  OR  DRIVE  UNIT  */VOLUME  ID 
INVALID  PARAMETER  IN  STATEMENT  ‘  ’  v. 

ERROR  ON  SX  PARAMETER 
SX  PARAMETER  NOT  VALID  FOR  SCRATCH 
ERROR  ON  QUEUE  PARAMETER 
QUEUE  NAME  GREATER  THAN  TEN  CHARACTERS 
QUEUE  NAME  SPECIFIED  TWICE 
EXCEED  NO  OF  STATEMENTS,  LIMIT=46 
NON- NUMERIC  STATEMENT  NO 
QUEUE  NAME  NOT  FOUND 
SPECIFIC  ENTRY  MD.MO  NOT  FOUND 
MD  ENTRIES  MOVED  TO  QUEUE  Ml OA 
MD  ENTRIES  SCRATCHED  FROM  QUEUE  MlOA 
OP  CODE  INVALID  ON  RETURN— CALL  SYSTEMS 
DETAIL  SUMMARY  FOR  MlOA  MIL 
SHORT  SUMMARY  FOR  MlOA  MIL 
MD  ENTRIES  -  HIGHEST  PRIORITY  MA 
PRI  STMT  NO  DATE  *  TIME 
MA  Mil  A  MD/MD/MD  M7A  MD 

DISPLAY  QUEUE  IS  EMPTY  " 

MASTER  TERMINAL  MAY  DISPLAY  SPECIFIC  MSG  ONLY  FROM  OWN  QUEUE 

MASTER  TERMINAL  MUST  REQUEST  SUM  OF  OTHER  QUEUE 

QUEUE  NAME  CAN  ONLY  BE  OWN  ORG  OH  OPER 

ONLY  ONE  STATEMENT  NO  CAN  BE  SPECIFIED 

BOTH  QUEUE  AND  SUM  KEYWORDS  SPECIFIED 

INVALID  PRIORITY  SPECIFIED 

QUEUE  NAME  ALREADY  IN  AUTO  MODE 
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OCD QUEUE  TERMINATED 
DOU  QUEUE  TERMINATED 
CAM  ONLY  SCRATCH  OWN  QUEUE 

LINE  !S,IZ.E  NOT  LARGE  ENOUGH FOR  DETAIL,' SUMMARY  GIVEN 
DISPLAY  Q=ALL  VALID  ONLY  FROM  MASTER  TERMINAL 
QUEUE  .NAME ;  ,  NO.  OF  ENTRIES 

REMOTE  ACCESS  COUNT  ERROR 

REMOTE  —  INVALID  ICF  FORMAT  '  :  .  • 

REMOTE  -  UNA3LE  TO  ATTACH  TO  REMOTE  SITE 

REMOTE  —  .UNEXPECTED  LINE  BREAK  'V;  ,.  ,  ... 

REMOTE  '--.INVALID  INTERUP.T  CODE  .  ••  •'  , 

3  SDR  1 7  --  COaricCT  TO  IDHSC-H  COMPLETE  '■  "  '  . 

GSDRIV  --  INVALID  REQUEST  ‘  ' 

GSDRIV  --  UNABLE  TO  CONNECT  TO  IOHSC-H 
GSDRIV  --  UNABLE  TO  ACCESS  .GLOBAL  COMREG  ■ 

GSDRIV  --  UNABLE  TO  MAP  TO  &FRTSK 

GSDRIV  --  RECEIVED  INVALID  ICF'  .... 

GSDRIV,-  UNABLE  TO  ROLL-IN  REMOTE  TASK  ' 

COMSPL  --  INVALID  REQUEST  -  TOO  MANY  FILE  SPECIFICATIONS' 

COMSPL  --  INVALID  FILE  SPECIFICATION 

COMSPL  -  OPEN  ERROR  ON  OUTPUT  FILE 

COMSPL  —  MSNTOS  FILE  "SO"  NOT  PROCESSED 

REMOTE  USER  MESSAGE '  FROM  ’.LIUA  AT  SITE:"2A  FOR  vVA 

COMSPL  —  MESSAGE  EXCEEDS  DIRECTED  OUTPUT  SPOOL  CAPACITY 

COMSPL  UNABLE  to  QUEUE  MESSAGE  FOR  SlOA 

READX  —  SEND  DATA  FAILURE  TO  SIR  ,  \ 

READX  -  READ  FAILURE  FROM  SIR 

WRITE X  -  SEND  DATA  FAILURE  TO  SIR 

WRITEX  -  WRITE  FAILURE  FROM  SIR 

CLOSEX  —  SEND  DATA  FAILURE  TO  SIR 

CLOSEX  —  CLOSE  FAILURE  FROM  SIR 

IOWHPR  -SEND  DATA  FILAURE  TO  SIR 

IOWHPR  —  WRITE  HISTORY  FAILURE  FROM  SIR 

IOWKT  —  SEND  DATA  FAILURE  TO  SIR 

IOW HI  —  WRITE  HISTORY  FAILURE  FROM  SIR 

UPWIC  —  IDHSC-1I  IS  ALREADY  ACTIVE 

UrWIC  -»  DSW  ERROR  ON  SEND/DATA  TO  GSTASK 

UPWIC  ~  REQUEST  SENT  TO  GSTASK 

INDO  --  GSTASK  NOT  INITIALIZED  DSW  ERROR  SO 

TNDO  —  GSTASK  NOT  INITIALIZED  QIC  ERROR  SO 

FILE  TRANS.  FROM  SlOA  AT  SITE:S1.A  S1L  FILE  SPECIFICATION  SVA 

YROD  —  SPOOL  OVERFLOW- DATA  LOST 

INVALID  FAILSOFT  CODE 
EXTENDED  STORAGE  EXHAUSTED  • 

SPAT  OVERFLOW 

HISTORY  ERROR 

DATA  BASE  I/O  ERROR 

END  Or  AVAILABLE  SPACE 

LINK  TABLE  OVERFLOW  - 

DATA  BASE  EXTENDS  EXCEEDED 

RECORD  acce:;  CONTROL  ERROR 
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INVALID  EXTENDED  STORAGE  SU8P00L  ’  . 

TERMINAL  OUTPUT  LENGTH  EXCEPTION  • 

INVALID  PAGE 

ENTRY  POINT  NOT  ON  PAGE 

LINK  TABLE  UNDERFLOW  . 

UNDEFINED  ENTRY  POINT  • 

DATA  BASE  RECORD  MAP  ERROR 

FS  —  TASK=?,2R,  TI=*2AX0 

GSTSK  —  UNABLE  TO  RUN  DISSEMINATOR  TASK 

GSTSK  —  DISSEMINATOR  TASK  (GS)  NOT  INSTALLED  ' 

DISCOM  —  NO  INPUT  FOUND  ON  D1  CALL  '  .  .  ;■  .  -'t- 

DISCOM  -  NO  INPUT  FOUND  0N.D2  CALL  'V  ■  /•'. 

DISCOM  -  D1  AREA  TOO  SMALL  FOR  'HEADFR  ’  .  .  a'-""', 

DISCOM  —  D2  AREA  TOO  SMALL  FOR  HEADER  <. 

DISCOM  —  ERRONEOUR  KEY  FOUND  BY  D1 

DISCOM  —  ERRONEOUS  KEY  FOUND  BY  D2 

DISCOM  —  D1  INPUT  W/O  HEADER  TERMINATOR 

DISCOM  --  D2  INPUT  W/O  HEADER  TERMINATOR  '  ;  . 

DISCOM--  D1  INPUT  LINK  LOST 

DISCOM  —  D2  INPUT  LINK  LOST 

DISCOM  —  Cl  VALUE  EXCEEDS  CHAR  LIMIT 

DISCOM  —  D2  VALUE  EXCEEDS  CHAR  LIMIT;  •  .  •••■•  ■ 

DISCOM  --  ERRONEOUS  VALUE  FOUND  BY  ‘<1 
DISCOM  -  ERRONEOUS  VALUE  FOUND  BY  D? 

DISADD  --  DISSEM,  ADD  CONSTRUCT  L/P  END  IMPROPERLY 
DISADD  -  DISSEM,  ADD  CONSTRUCT  O/O  END  IMPROPERLY 
DISADD  --  JINTACCS  HEADER  SEQUENCE  ERROR 
DISADD  -  ..1INTACCS  RECORD  ID  NOT  SPECIFIED 
INPROF  —  IRE  DEFINITION  ERROR  , 

INPROF  --  FACTOR  INCLUDE/EXCLUDE  ERROR  > 

INPROF  -  FACTOR  KEYWORD  ERROR 
INPROF  —  VALUE  DEFINITION  ERROR 
INPROF  -  LINE  TERMINATION  ERROR 
INPROF  —  ENTRY  SIZE  ERROR 
INPROF  —  INPUT  HAS  UNPAIRED  QUOTE  MARK 
INPROF  —  USER  DEFINITION  ERROR 
IORHT  -  SEND  DATA  FAILURE  TO  . 

IORHT  —  READ  HISTORY  FAILURE  FROM  %'t  $ 

RECEIVE  DATA  FAILURE 
CORE  BLOCK  REQUEST  FAILURE 
SUPERVISOR  DIRECTIVE  FAILURE 
WRITEX  —  WRITE  RANDOM  ILLEGAL 
CLOSEX  —  FAILED  TO  DELETE  FILE 
MOUNT  SCRATCH  TAPE 
MOUNT  SCRATCH  TAPE  AS  FOREIGN 
MOUNT  TAPE(S)  %VA 
MOUNT  TAPE(S)  %VA  AS  FOREIGN 
DENSITY  =  1600  BPI 
DISMOUNT  TAPE  ON  DRIVE  SVA 
INVALID  RESPONSE 

FILE  %VA  ON  VOLUME($T“%VA  HAS  BEEN  CLOSED  WITH  OPTION  XVA 

FILE  XVA  HAS  BEEN  CLOSED  WITH  OPTION  XXX 

LAST  BLOCK  PROCESSED  =  »VA,  LAST  RECORD  PROCESSED  «  XVA 
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